libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] option detection failures


From: Christian Cornelssen
Subject: [PATCH] option detection failures
Date: Mon, 28 Oct 2002 16:04:32 +0100 (CET)

Dear libtool maintainers,

I have checked out Libtool 1.4e (1.1147 2002/10/25 03:28:42)
and found that it still failed to detect simultanous "-c -o"
support correctly.  In non-tagged versions, this was due to
the save_xxxFLAGS kludges intended to indirectly add options
to $ac_compile.  This method is neither nestable (the save_*
variables do not form a stack) nor applicable to languages that
are unknown to libtool.  Worse, the "-c -o" detection now failed
even for plain C!  Therefore I set out to replace 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 some $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.  This saves lots of tag-dependent
code for guessing, saving, and restoring *FLAGS variables.  As a
side effect, the GCJFLAGS/CFLAGS restoration bug has been eliminated.

The new method simply makes use of the fact that $ac_compile
contains a literal "conftest.".  More precisely, the additional
option is inserted before the first word following a blank and
containing "conftest.".  The word does not need to begin with
"conftest.", hence a path, an option or a redirection operator could
be prefixed.  If $ac_compile should ever happen to not contain a
literal "conftest.", the additional option is appended at the end.
This ensures that $lt_compile gets both $ac_compile and the new
option, and very probably in a useful order.  (The FLAGS-based
approach did not guarantee the insertion, but if it happened,
the order could be expected to be ok.)

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 and thereby cause some feature detections to fail.
This had really happened in some "static" flag detection
attempts where gcc warned about an implicit "int" return type.
Similarly, the -lc link test used a fixed C-style conftest
instead of $lt_simple_compile_test_code.  I have changed that too.
Additionally, I have removed a redundant "-c conftest.$ac_ext"
in the "-fno-rtti -fno-exceptions" test.

BTW, is it intended that AC_LIBTOOL_COMPILER_OPTION does not
explicitly remove $ac_outfile?

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.

- 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.

Best regards,

Christian Cornelssen

Attachment: libtool-1.4e-1.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]