* Re: [RFC] Update to current automake/autoconf/libtool versions.
@ 2002-12-05 14:36 Nathanael Nerode
2002-12-05 15:19 ` Zack Weinberg
0 siblings, 1 reply; 10+ messages in thread
From: Nathanael Nerode @ 2002-12-05 14:36 UTC (permalink / raw)
To: zack, gdb-patches, binutils, newlib, gcc
>I'd like to remind everyone involved that last I checked it was flat
>impossible to do what libstdc++-v3/configure.in needs to do, using
>autoconf 2.5x. I am not particularly sanguine about the situation
Flat impossible?
Wow.
And for the top level, all I had to do was define my own entire set of
macros to replace the AC_CHECK_TOOL and AC_PROG_* collection. :-)
I'd be interested to hear more about the problem. Why can't it be dealt
with by using private macros?
--Nathanael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 14:36 [RFC] Update to current automake/autoconf/libtool versions Nathanael Nerode @ 2002-12-05 15:19 ` Zack Weinberg 2002-12-06 9:33 ` Tom Tromey 2002-12-07 12:55 ` Alexandre Oliva 0 siblings, 2 replies; 10+ messages in thread From: Zack Weinberg @ 2002-12-05 15:19 UTC (permalink / raw) To: Nathanael Nerode; +Cc: gdb-patches, binutils, newlib, gcc Nathanael Nerode <neroden@twcny.rr.com> writes: >>I'd like to remind everyone involved that last I checked it was flat >>impossible to do what libstdc++-v3/configure.in needs to do, using >>autoconf 2.5x. I am not particularly sanguine about the situation > > Flat impossible? > > Wow. Like I said, I'd be delighted to be proved wrong. > I'd be interested to hear more about the problem. Why can't it be > dealt with by using private macros? It was a couple years ago, but I think I still remember pretty clearly. First off, you've probably met this stuff (from libstdc++/aclocal.m4): # Never versions of autoconf add an underscore to these functions. # Prevent future problems ... ifdef([AC_PROG_CC_G],[],[define([AC_PROG_CC_G],defn([_AC_PROG_CC_G]))]) ifdef([AC_PROG_CC_GNU],[],[define([AC_PROG_CC_GNU],defn([_AC_PROG_CC_GNU]))]) ifdef([AC_PROG_CXX_G],[],[define([AC_PROG_CXX_G],defn([_AC_PROG_CXX_G]))]) ifdef([AC_PROG_CXX_GNU],[],[define([AC_PROG_CXX_GNU],defn([_AC_PROG_CXX_GNU]))]) # AC_PROG_CC # FIXME: We temporarily define our own version of AC_PROG_CC. This is # copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS. We # are probably using a cross compiler, which will not be able to fully # link an executable. This is addressed in later versions of autoconf. AC_DEFUN(LIB_AC_PROG_CC, [AC_BEFORE([$0], [AC_PROG_CPP])dnl dnl Fool anybody using AC_PROG_CC. AC_PROVIDE([AC_PROG_CC]) AC_CHECK_PROG(CC, gcc, gcc) if test -z "$CC"; then AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc) test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) fi AC_PROG_CC_GNU if test $ac_cv_prog_gcc = yes; then GCC=yes dnl Check whether -g works, even if CFLAGS is set, in case the package dnl plays around with CFLAGS (such as to build both debugging and dnl normal versions of a library), tasteless as that idea is. ac_test_CFLAGS="${CFLAGS+set}" ac_save_CFLAGS="$CFLAGS" CFLAGS= AC_PROG_CC_G if test "$ac_test_CFLAGS" = set; then CFLAGS="$ac_save_CFLAGS" elif test $ac_cv_prog_cc_g = yes; then CFLAGS="-g -O2" else CFLAGS="-O2" fi else GCC= test "${CFLAGS+set}" = set || CFLAGS="-g" fi ]) This is a clone of the 2.13 AC_PROG_CC with some minor modifications: specifically, the AC_PROG_CC_WORKS call was removed. With autoconf 2.50+, the internal structure of AC_PROG_CC is totally different, and this definition breaks. (The "newer versions of autoconf" stuff was someone's attempt to fix it, but it doesn't work.) Someone on the autoconf team knew about this and tried to help out by providing an undocumented macro called AC_NO_EXECUTABLES: # AC_NO_EXECUTABLES # ----------------- # FIXME: The GCC team has specific needs which the current Autoconf # framework cannot solve elegantly. This macro implements a dirty # hack until Autoconf is abble to provide the services its users # needs. # # Several of the support libraries that are often built with GCC can't # assume the tool-chain is already capable of linking a program: the # compiler often expects to be able to link with some of such # libraries. # # In several of these libraries, workarounds have been introduced to # avoid the AC_PROG_CC_WORKS test, that would just abort their # configuration. The introduction of AC_EXEEXT, enabled either by # libtool or by CVS autoconf, have just made matters worse. AC_DEFUN_ONCE([AC_NO_EXECUTABLES], [m4_divert_push([KILL]) AC_BEFORE([$0], [_AC_COMPILER_EXEEXT_WORKS]) AC_BEFORE([$0], [_AC_COMPILER_EXEEXT]) m4_define([_AC_COMPILER_EXEEXT_WORKS], [cross_compiling=maybe ]) m4_define([_AC_COMPILER_EXEEXT], [EXEEXT= ]) m4_define([AC_LINK_IFELSE], [AC_FATAL([All the tests involving linking were disabled by $0])]) m4_divert_pop()dnl ])# AC_NO_EXECUTABLES (lang.m4 from autoconf 2.56) AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf to barf if an AC_TRY_LINK test appears anywhere in the script being generated. libstdc++-v3/configure.in has lots of AC_TRY_LINK tests. They are only executed in a native compilation, but that's not good enough for AC_NO_EXECUTABLES. Going over it all again, I realize that we could probably just redefine AC_NO_EXECUTABLES to do what we want. We'd have to specialize its definition for every version of autoconf that we cared about, and check at every new release that it hadn't broken, but it would work. I guess it's not impossible after all. zw ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 15:19 ` Zack Weinberg @ 2002-12-06 9:33 ` Tom Tromey 2002-12-07 12:55 ` Alexandre Oliva 1 sibling, 0 replies; 10+ messages in thread From: Tom Tromey @ 2002-12-06 9:33 UTC (permalink / raw) To: Zack Weinberg; +Cc: gdb-patches, binutils, newlib, gcc >>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes: Zack> Someone on the autoconf team knew about this and tried to help out by Zack> providing an undocumented macro called AC_NO_EXECUTABLES: Zack> # FIXME: The GCC team has specific needs which the current Autoconf Zack> # framework cannot solve elegantly. This macro implements a dirty Zack> # hack until Autoconf is abble to provide the services its users Zack> # needs. Zack> They are only executed in a native compilation, but that's not good Zack> enough for AC_NO_EXECUTABLES. Presumably if AC_NO_EXECUTABLES exists solely for the use of gcc, then it could be changed to do what gcc actually requires. Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 15:19 ` Zack Weinberg 2002-12-06 9:33 ` Tom Tromey @ 2002-12-07 12:55 ` Alexandre Oliva 2002-12-07 13:19 ` Zack Weinberg 2002-12-08 13:48 ` [RFC] Update to current automake/autoconf/libtool versions Tom Tromey 1 sibling, 2 replies; 10+ messages in thread From: Alexandre Oliva @ 2002-12-07 12:55 UTC (permalink / raw) To: Zack Weinberg; +Cc: Nathanael Nerode, gdb-patches, binutils, newlib, gcc On Dec 5, 2002, Zack Weinberg <zack@codesourcery.com> wrote: > AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of > AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf > to barf if an AC_TRY_LINK test appears anywhere in the script being > generated. Please tell me why (2) doesn't make sense. If AC_PROG_CC_WORKS can't even link a do-nothing program, how would you expect to get any useful results from AC_TRY_LINK? > libstdc++-v3/configure.in has lots of AC_TRY_LINK tests. If we know AC_PROG_CC_WORKS fails, it is a mistake to use AC_TRY_LINK tests. Removing the constraint from autoconf will do us no good. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-07 12:55 ` Alexandre Oliva @ 2002-12-07 13:19 ` Zack Weinberg 2002-12-09 18:57 ` Alexandre Oliva 2002-12-08 13:48 ` [RFC] Update to current automake/autoconf/libtool versions Tom Tromey 1 sibling, 1 reply; 10+ messages in thread From: Zack Weinberg @ 2002-12-07 13:19 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Nathanael Nerode, gdb-patches, binutils, newlib, gcc Alexandre Oliva <aoliva@redhat.com> writes: > On Dec 5, 2002, Zack Weinberg <zack@codesourcery.com> wrote: > >> AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of >> AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf >> to barf if an AC_TRY_LINK test appears anywhere in the script being >> generated. > > Please tell me why (2) doesn't make sense. > > If AC_PROG_CC_WORKS can't even link a do-nothing program, how would > you expect to get any useful results from AC_TRY_LINK? Because libstdc++'s AC_TRY_LINK tests are only executed in a situation where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation). zw ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-07 13:19 ` Zack Weinberg @ 2002-12-09 18:57 ` Alexandre Oliva 2002-12-09 21:52 ` Geoff Keating 0 siblings, 1 reply; 10+ messages in thread From: Alexandre Oliva @ 2002-12-09 18:57 UTC (permalink / raw) To: Zack Weinberg; +Cc: Nathanael Nerode, gdb-patches, binutils, newlib, gcc On Dec 7, 2002, Zack Weinberg <zack@codesourcery.com> wrote: > Alexandre Oliva <aoliva@redhat.com> writes: >> On Dec 5, 2002, Zack Weinberg <zack@codesourcery.com> wrote: >> >>> AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of >>> AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf >>> to barf if an AC_TRY_LINK test appears anywhere in the script being >>> generated. >> >> Please tell me why (2) doesn't make sense. >> >> If AC_PROG_CC_WORKS can't even link a do-nothing program, how would >> you expect to get any useful results from AC_TRY_LINK? > Because libstdc++'s AC_TRY_LINK tests are only executed in a situation > where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation). I don't get it. Why does being able to link have anything to do with being native? Being able to *run* tests has to do with being native, but that's not the point, and autoconf already avoids running tests when cross-building. But being able to link has to do with whether the libraries that the compiler links in by default are present or not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests while building a library that the compiler driver would attempt to link in by default, such as newlib, libstdc++ or libgcj. That said, I'm not sure it should be used for libstdc++, since there's no reason to use g++: we should use gcc instead, even if we perform C++ link tests. Ditto for libjava, I suppose, but I realize it would be far trickier to get libjava to link C programs :-) Still, I think AC_NO_EXECUTABLES may affect all linking whatsoever, not only that of the language in effect at the point it appears, which does indeed make it useless for anything other that newlib. But, for newlib, preventing link tests *is* the right thing to do, and I contend that it's the right thing to do for any language affected by the AC_NO_EXECUTABLES declaration. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-09 18:57 ` Alexandre Oliva @ 2002-12-09 21:52 ` Geoff Keating 2002-12-09 22:10 ` AC_NO_EXECUTABLES is useless for GCC Alexandre Oliva 0 siblings, 1 reply; 10+ messages in thread From: Geoff Keating @ 2002-12-09 21:52 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Nathanael Nerode, gdb-patches, binutils, newlib, gcc Alexandre Oliva <aoliva@redhat.com> writes: > I don't get it. Why does being able to link have anything to do with > being native? Being able to *run* tests has to do with being native, > but that's not the point, and autoconf already avoids running tests > when cross-building. But being able to link has to do with whether > the libraries that the compiler links in by default are present or > not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests > while building a library that the compiler driver would attempt to link > in by default, such as newlib, libstdc++ or libgcj. Aah, I see. No, that's not the purpose of AC_NO_EXECUTABLES, or at least it's not what GCC wants out of it. Some platforms can't link anything at all without special care. For instance, you might need to know what board you plan to run the executable on and pass an appropriate flag (or supply an appropriate crt0 by hand). For another example, vxworks can't and doesn't link anything, the final link takes place at runtime on the board, "executables" are created using 'ld -r', and you can refer to any symbols you like in the hope that they'll be available later. It's assumed that in a native case, this sort of thing won't happen, thus the existing behaviour. Maybe instead you could perform a configure-time test to see if the platform can link anything at all (and will fail to link with an obviously bogus symbol), and then base the decision of whether to run link tests on that, instead of the current approximation, but there'll still be some cases when linking is not possible, and other cases (the majority) in which link tests are possible and desirable. -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 10+ messages in thread
* AC_NO_EXECUTABLES is useless for GCC 2002-12-09 21:52 ` Geoff Keating @ 2002-12-09 22:10 ` Alexandre Oliva 2002-12-09 22:27 ` Ian Lance Taylor 0 siblings, 1 reply; 10+ messages in thread From: Alexandre Oliva @ 2002-12-09 22:10 UTC (permalink / raw) To: Geoff Keating Cc: Nathanael Nerode, gdb-patches, binutils, newlib, gcc, autoconf On Dec 10, 2002, Geoff Keating <geoffk@geoffk.org> wrote: > Alexandre Oliva <aoliva@redhat.com> writes: >> I don't get it. Why does being able to link have anything to do with >> being native? Being able to *run* tests has to do with being native, >> but that's not the point, and autoconf already avoids running tests >> when cross-building. But being able to link has to do with whether >> the libraries that the compiler links in by default are present or >> not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests >> while building a library that the compiler driver would attempt to link >> in by default, such as newlib, libstdc++ or libgcj. > Aah, I see. No, that's not the purpose of AC_NO_EXECUTABLES, or at > least it's not what GCC wants out of it. Some platforms can't link > anything at all without special care. For instance, you might need to > know what board you plan to run the executable on and pass an > appropriate flag (or supply an appropriate crt0 by hand). For another > example, vxworks can't and doesn't link anything, the final link takes > place at runtime on the board, "executables" are created using 'ld > -r', and you can refer to any symbols you like in the hope that > they'll be available later. I see. Oh, well... I was missing this bit of info when I designed AC_NO_EXECUTABLES :-( My apologies... > It's assumed that in a native case, this sort of thing won't happen, > thus the existing behaviour. Maybe instead you could perform a > configure-time test to see if the platform can link anything at all > (and will fail to link with an obviously bogus symbol), and then base > the decision of whether to run link tests on that, instead of the > current approximation, but there'll still be some cases when linking > is not possible, and other cases (the majority) in which link tests > are possible and desirable. I think we'll be better served by declarative macros such as AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail out if it fails, but rather it sets a variable indicating the result of the test, such that we could base our decision on whether to perform additional link tests on this variable. Does it sound like this would work? Do we actually need AC_*_LINK_MAY_FAIL, or would a single AC_LINK_MAY_FAIL macro be sufficient for libstdc++ and libgcj's needs? Or perhaps we could make do with a configure argument that would tell autoconf it's ok if the initial link test fails. It could even short-circuit all other configure link tests, such that one might be able to configure a package containing link tests for a system that doesn't really support linking. The reason to not have this behavior enabled by default is that we do want to detect situations when the compiler is broken (the number of bogus reports caused by them used to be huge when we didn't do it), but if a standard configure argument disables the test, I think we're kind of ok. Thoughts? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: AC_NO_EXECUTABLES is useless for GCC 2002-12-09 22:10 ` AC_NO_EXECUTABLES is useless for GCC Alexandre Oliva @ 2002-12-09 22:27 ` Ian Lance Taylor 0 siblings, 0 replies; 10+ messages in thread From: Ian Lance Taylor @ 2002-12-09 22:27 UTC (permalink / raw) To: Alexandre Oliva Cc: Geoff Keating, Nathanael Nerode, gdb-patches, binutils, newlib, gcc, autoconf Alexandre Oliva <aoliva@redhat.com> writes: > I think we'll be better served by declarative macros such as > AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated > sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail > out if it fails, but rather it sets a variable indicating the result > of the test, such that we could base our decision on whether to > perform additional link tests on this variable. Does it sound like > this would work? This approach sounds weird to me. The basic problem is that AC_PROG_CC does the wrong thing for libstdc++ and a few other configure scripts--namely, it executes the test of whether the compiler works. It seems to me that AC_PROG_CC should call some helper macros--perhaps just two--and that libstdc++ should call a subset of those helper macros--perhaps just one. Adding macros which change the behaviour of other macros seems confusing. I don't see the advantage of that at all. Ian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-07 12:55 ` Alexandre Oliva 2002-12-07 13:19 ` Zack Weinberg @ 2002-12-08 13:48 ` Tom Tromey 1 sibling, 0 replies; 10+ messages in thread From: Tom Tromey @ 2002-12-08 13:48 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Nathanael Nerode, gdb-patches, binutils, newlib, gcc >>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes: >> But, (2) it causes autoconf to barf if an AC_TRY_LINK test appears >> anywhere in the script being generated. Alexandre> Please tell me why (2) doesn't make sense. Alexandre> If AC_PROG_CC_WORKS can't even link a do-nothing program, Alexandre> how would you expect to get any useful results from Alexandre> AC_TRY_LINK? The autoconf code in question completely disables AC_LINK_IFELSE. However, we know we can successfully do link tests when building natively. And, at least in libgcj's case, this knowledge is important because we use it to make libgcj more functional when built native. FYI I sent a patch to the autoconf list. Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-12-10 6:17 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-05 14:36 [RFC] Update to current automake/autoconf/libtool versions Nathanael Nerode 2002-12-05 15:19 ` Zack Weinberg 2002-12-06 9:33 ` Tom Tromey 2002-12-07 12:55 ` Alexandre Oliva 2002-12-07 13:19 ` Zack Weinberg 2002-12-09 18:57 ` Alexandre Oliva 2002-12-09 21:52 ` Geoff Keating 2002-12-09 22:10 ` AC_NO_EXECUTABLES is useless for GCC Alexandre Oliva 2002-12-09 22:27 ` Ian Lance Taylor 2002-12-08 13:48 ` [RFC] Update to current automake/autoconf/libtool versions Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).