[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] option detection failures
From: |
Christian Cornelssen |
Subject: |
Re: [PATCH] option detection failures |
Date: |
Tue, 29 Oct 2002 15:44:35 +0100 (CET) |
Dear libtool developers,
(This is a posting merged from earlier submissions that did not make
it into the mailing list because I had not subscribed before.)
I have checked out the mainline of Libtool 1.4e (1.1147 2002/10/25
03:28:42), actually by downloading
`ftp://ftp.alpha.gnu.org/gnu/cvs/libtool-20021011.tgz' and doing a
"cvs update" in 2002/10/25.
I found that the above version still fails to detect simultanous "-c
-o" support and other options correctly. In non-tagged versions with
non-C language, this was due to the save_CFLAGS kludges intended to
indirectly add options to $ac_compile. Note that that method is
neither nestable (the save_* variables do not form a stack) nor
applicable to languages that are unknown to libtool (and this might
happen even with a "tagged" version). But worse, the "-c -o"
detection now failed even for plain C! Therefore I set out to reduce
the save_* mess and fix the compiler option detection macros.
The attached patch mainly changes AC_LIBTOOL_COMPILER_OPTION and
AC_LIBTOOL_PROG_CC_C_O in `libtool.m4'. Instead of assuming that
$ac_compile contains specific $xxxFLAGS and modifying these for an
"eval $ac_compile", the new method copies $ac_compile into another
variable (lt_compile) and thereby inserts the to-be-tested option(s).
Then $lt_compile is evaluated. Since $lt_compile is used only in an
immediately following eval, the need to save and restore variables has
been eliminated.
The new method simply makes use of one of two characteristics: namely
that $ac_compile contains references like $xxxFLAGS or ${xxxFLAGS}
and/or a literal "conftest.". The to-be-tested option is inserted
either after the last FLAGS reference, or before the first word
containing "conftest.", or at the end. This approach replaces quite a
few lines of tag-dependent code for guessing specific *FLAGS
variables. As a side effect, a GCJFLAGS/CFLAGS restoration bug has
been eliminated: Inspect the attached patch for details.
Note also that the to-be-tested option is now guaranteed to be passed
to the compiler.
Besides, appropriate logging has been added. Previously, stderr
messages were added to the log only if the compilation succeeded :-(
The improved logging revealed an additional bug related to
$lt_simple_compile_test_code, which could contain "\n". So it should
be output by printf, which is what AC_LIBTOOL_COMPILER_OPTION does,
but AC_LIBTOOL_PROG_CC_C_O used echo instead. I have changed the
echo to printf in that place. (There are so many printf commands
spread around that I have decided not to try to eliminate them.)
That bug was the actual cause of the failure to detect "-c -o"
support: It caused an error about a "stray \ in program".
Furthermore, I fixed some lt_simple_compile_test_code and
lt_simple_link_test_code settings which could otherwise trigger
warnings (when compiled with "-Wall" for example) and thereby cause
some feature detections to fail. I also found that the -lc link test
used a fixed C-style conftest instead of $lt_simple_compile_test_code.
I have changed that too. Moreover, a redundant "-c conftest.$ac_ext"
in the "-fno-rtti -fno-exceptions" test has been removed.
BTW, is it intended that AC_LIBTOOL_COMPILER_OPTION does not
explicitly remove $ac_outfile? (Only conftest* is deleted.)
With the patch (and a subsequent ./bootstrap) applied, the detection
of "-c -o" support and other compiler options now works at least
with gcc, g++, g77, and gcj, and should be more robust.
There is still some "save_*" stuff left in `libtool.m4', notably
in AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE (manipulating CFLAGS), and in
some other places where LDFLAGS and/or CPPFLAGS are manipulated.
Using the new method there (preferably as a new macro) could increase
consistency; however, I did not see an immediate benefit therein,
and I wanted to keep the patch small. If you would like to extend
the patch, please tell me so.
Some annoying bugs are still left:
- "configure" variables like CC etc. are not passed to the *demo
subdirectories. This can break some tests.
- GCC compilers are not tested for "-static", but for an empty option.
- Even if a Fortran compiler has not been found, some option
tests are performed with the empty $F77, resulting in messages
like "checking if PIC flag -fPIC works", "checking if supports
-c -o file.o", and the like.
Should I switch to a multi-language branch?
Best regards,
Christian Cornelssen
libtool-1.4e-2.patch
Description: Text document
- [PATCH] option detection failures, Christian Cornelssen, 2002/10/28
- Re: [PATCH] option detection failures, Christian Cornelssen, 2002/10/29
- Re: [PATCH] option detection failures,
Christian Cornelssen <=
- Re: [PATCH] option detection failures, Charles Wilson, 2002/10/29
- Re: [PATCH] option detection failures, Christian Cornelssen, 2002/10/29
- Re: [PATCH] option detection failures, Bob Friesenhahn, 2002/10/29
- Re: [PATCH] option detection failures, Christian Cornelssen, 2002/10/29
- Re: [PATCH] option detection failures, Boehne, Robert, 2002/10/30