mainAutoconf - Support: sr #110350, AX_PROG_CC_FOR_BUILD broken with...

 
 

sr #110350: AX_PROG_CC_FOR_BUILD broken with 2.69c

Submitter:  Zack Weinberg <zackw>
Submitted:  Fri 30 Oct 2020 09:18:51 PM UTC
   
 
Priority:  * 5 - Unprioritized Severity:  3 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 04 Dec 2020 09:42:16 PM UTC, comment #4: 

Fixed in c38538737c6d221674b9bc746b6b1430f64d4aaa.

Zack Weinberg <zackw>
Group administrator
Wed 18 Nov 2020 12:59:06 AM UTC, comment #3: 

I think I understand.  Trying to define a test case feels a bit like you're trying to formalize what was a somewhat kludgy workaround to begin with.

Given the way AX_PROG_CC_FOR_BUILD currently works, it's hard to see any way of supporting it that doesn't rely (implicitly or explicitly) on whether CC is defined as a macro.

On the other hand, AX_PROG_CC_FOR_BUILD also relies on setting shell variables before/after running the checks, so it requires that the checks be performed at the location where AC_PROG_CC appears in the code.

So one option would be to define the body of AC_PROG_CC as a shell function, where the name of the function is [ac_fn_prog_]CC or something like that - so with AX_PROG_CC_FOR_BUILD you end up with ac_fn_prog_CC() that sets $CC and $CFLAGS, and ac_fn_prog_CC_FOR_BUILD() that sets $CC_FOR_BUILD and $CFLAGS_FOR_BUILD.  The result would be similar to Autoconf 2.69 in performance - multiple instances of AC_PROG_CC would call ac_fn_prog_CC() multiple times, but the result would be cached.  But this would still serve the goal of reducing the size of configure.

Another option would be to make the workaround explicit, saying that if CC is defined as a macro, then we run the checks at the location where AC_PROG_CC appears (perhaps through a shell function, perhaps not), and if CC is not defined then we merely require the checks to be performed prior to the current macro.

With an explicit "ifdef" it's also possible to show a warning that this usage is deprecated.

Benjamin Moody <bmoody>
Tue 17 Nov 2020 04:49:35 PM UTC, comment #2: 


> is maintaining compatibility the sticking point, or is it that you want a better API to enable what AX_PROC_CC_FOR_BUILD did?


Right now we want to maintain compatibility.  Developing a better API and fixing the problem within ax_prog_cc_for_build.m4 would both take too long for the 2.70 release timeframe.

> how important is it to use AC_DEFUN_ONCE for AC_PROG_CC?


I honestly don't know.  The change was made eight years ago with very little rationale - see https://lists.gnu.org/archive/html/autoconf-patches/2012-09/msg00034.html , which was committed nearly verbatim.

It would be simple enough to revert that change, but I would want to write tests to ensure this doesn't break again (at least not until we do have a better API) and it might make sense to try to accomplish the goal of the change - reducing the size of a generated configure script - some other way (e.g. factoring out as much as possible of the code emitted by AC_PROG_CC to a shell function).

Zack Weinberg <zackw>
Group administrator
Mon 16 Nov 2020 11:46:05 PM UTC, comment #1: 

It's not entirely clear to me what the issue is - is maintaining compatibility the sticking point, or is it that you want a better API to enable what AX_PROC_CC_FOR_BUILD did?

I also don't understand what Jannick's proposed solution would be, though my M4 is not the best.

First of all, how important is it to use AC_DEFUN_ONCE for AC_PROG_CC?  Autoconf 2.69 does cache the result of AC_PROG_CC, after all.  So maybe the simplest thing would be to revert that change and keep things working as they were in 2.69.

If optimizing AC_PROG_CC is necessary, how important is it to preserve compatibility with the existing AX_PROC_CC_FOR_BUILD macro?  I don't think it would be too much of a burden to tell people "when you upgrade to Autoconf 2.70, you will also need to get an updated version of ax_prog_cc_for_build.m4".  Of course, that would rely on there being an updated ax_prog_cc_for_build.m4 - is there a proposed alternative that would work in the presence of AC_DEFUN_ONCE'd AC_PROG_CC?

If it's essential both to optimize AC_PROG_CC to avoid multiple expansions, and to avoid breaking AX_PROC_CC_FOR_BUILD, how ugly is the implementation allowed to be? :)  It seems to me that you could change AC_PROG_CC to something like:


AC_DEFUN([AC_PROG_CC],
dnl  If the macro CC is locally defined (e.g. by AX_PROG_CC_FOR_BUILD,
dnl  which defines it as CC_FOR_BUILD), then perform the compiler
dnl  tests each time AC_PROG_CC is invoked.  If CC is undefined, then
dnl  we only want to include the tests once.
[m4_ifdef([CC],
[_AC_PROG_CC_REALLY_I_MEAN_IT($@)],
[_AC_PROG_CC_ONLY_ONCE($@)])])

AC_DEFUN_ONCE([_AC_PROG_CC_ONLY_ONCE],
[_AC_PROG_CC_REALLY_I_MEAN_IT($@)])

AC_DEFUN([_AC_PROG_CC_REALLY_I_MEAN_IT],
[AC_LANG_PUSH(C)dnl
AC_ARG_VAR([CC],     [C compiler command])dnl
AC_ARG_VAR([CFLAGS], [C compiler flags])dnl
...
AC_LANG_POP(C)dnl
])# AC_PROG_CC


I'm sure this could be done much more elegantly, but it seems to work in a simple test.

Benjamin Moody <bmoody>
Fri 30 Oct 2020 09:18:51 PM UTC, original submission:  

From https://lists.gnu.org/r/autoconf/2020-10/msg00048.html :

AX_PROC_CC_FOR_BUILD calls AC_PROG_CC after switching (hopefully) all
compiler variables and settings to CC_FOR_BUILD to then run the relevant
tests.

The culprit commit
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=18c140b50b
0619454d4da50d58a318cc257d580a
requires AC_PROG_CC to be executed just once in configure which, for this
approach to make autoconf define CC_FOR_BUILD and friends, is a bridge too
far I believe.  This commit makes autoconf ignore AC_PROG_CC in
AX_PROC_CC_FOR_BUILD such that the variable CC_FOR_BUILD is empty and the
compilation command like '$CC_FOR_BUILD conftest.c' called by configure
fails.

Here a suggestion for a way out with a more careful approach assuming the
commit above be reverted: Run AC_PROG_CC and add the pair
(LANGUAGE,COMPILERNAME) to a set (say, ABC) unless the pair was already
seen, i.e. is in set ABC ('m4_set_add' could help here).  This would I think
come with the need to add optional arguments to AC_PROG_CC which would be a
step further to have autoconf itself tackle cross-compilation issues.

Zack Weinberg <zackw>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bmoody (Posted a comment)
  • -email is unavailable- added by zackw (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-04 zackw StatusNone Done
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code