Re: [PATCH] option detection failures

[Christian Cornelssen]

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