Re: [PATCH] option detection failures

[Christian Cornelssen]

On Tue, 29 Oct 2002, Albert Chin wrote:

> Please repost with a unified diff (diff -u).

OK, the attached diff is now in -u format.

On Tue, 29 Oct 2002, Christian Cornelssen wrote:

> 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