Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O

[Jeff Squyres]

Greetings / happy new year!

Although someone on this list has agreed with me on the validity of the
patch listed below, it has not yet been applied to libtool's CVS (I
started asking about 2 months ago).  If this patch is to be rejected, no
problem, but please give some kind of NACK response.

My patch and the original mail describing the problem is included below.

Thanks!

-----
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.25
diff -u -r1.25 libtool.m4
--- m4/libtool.m4       2 Jan 2004 02:18:03 -0000       1.25
+++ m4/libtool.m4       2 Jan 2004 19:43:03 -0000
@@ -993,13 +993,6 @@

    mkdir out
    printf "$lt_simple_compile_test_code" > conftest.$ac_ext

-   # According to Tom Tromey, Ian Lance Taylor reported there are C compilers
-   # that will create temporary files in the current directory regardless of
-   # the output directory.  Thus, making CWD read-only will cause this test
-   # to fail, enabling locking or at least warning the user not to do parallel
-   # builds.
-   chmod -w .
-
    lt_compiler_flag="-o out/conftest2.$ac_objext"
    # Insert the option either (1) after the last *FLAGS variable, or
    # (2) before a word containing "conftest.", or (3) at the end.
-----



On Wed, 5 Nov 2003, Jeff Squyres wrote:

> Short version:
> --------------
>
> Problem: Libtool's AC_LIBTOOL_PROG_CC_C_O m4 macro (in m4/libtool.m4)
> executes "chmod -w ." before testing to see if the compiler supports "$CC
> -c foo.c -o whatever".  This causes the Intel compiler on Linux (icc) to
> fail because it tries to write temporary files in the pwd regardless of
> the output directory.
>
> Through a long sequence of cause-and-effects, this eventually causes a
> failure of Automake/Libtool to build libraries when using Automake's
> _CPPFLAGS suffix functionality.
>
> Solution: Removing the "chmod -w ." does not seem to have any adverse
> effects, and makes the Intel compiler pass this test (as it should,
> because icc supports "icc -c foo.c -o whatever"), and therefore Automake's
> _CPPFLAGS functionality works as expected.
>
> Additional details and supporting rationale included below.
>
> Longer version:
> ---------------
>
> The AC_PROG_LIBTOOL_PROG_CC_C_O m4 macro executes a "chmod -w ."
> before running the test compile to see if the compiler supports -c and
> -o simultaneously.
>
> This causes icc to always fail the test because icc apparently makes
> temp files in the pwd regardless of the output directory specified by
> -o.  Hence, since icc can't write to ., the test fails.
>
> Here is a sample from config.log:
>
> -----
> configure:6286: checking if icc supports -c -o file.o
> configure:6317: icc -c -g  -o out/conftest2.o conftest.c >&5
> icc: error: unable to open 'iccFZIGkggas'
> configure:6321: $? = 0
> configure:6335: result: no
> -----
>
> The error from icc is obvious -- it didn't succeed because it couldn't
> write to the pwd.  Hence, it fails the test -- but for the wrong reason.
> As a matter of fact, icc *does* support -c/-o simultaneously, so the test
> unfairly comes to the wrong conclusion.
>
> Since libtool thinks that the compiler doesn't support -c and -o together,
> this causes badness much later when an Automake-generated Makefile
> executes the following (forgive mail client line wrapping):
>
> -----
> source='one.c' object='libone_la-one.lo' libtool=yes \
> depfile='.deps/libone_la-one.Plo' tmpdepfile='.deps/libone_la-one.TPlo' \
> depmode=icc /bin/sh ./depcomp \
> /bin/sh ./libtool --mode=compile icc -DPACKAGE_NAME=\"\"
> -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
> -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_DLFCN_H=1  -I. -I.  -DONE_EXTRA_FLAG=1 -DFOO=1   -g -c -o
> libone_la-one.lo `test -f 'one.c' || echo './'`one.c
> -----
>
> Notice that Automake specified "-o libone_la-one.lo".  However,
> libtool re-echos this command without the -o (because it thinks the
> compiler doesn't support it):
>
> -----
>  icc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_DLFCN_H=1 -I. -I. -DONE_EXTRA_FLAG=1 -DFOO=1 -g -c one.c -MD
> -MF .deps/libone_la-one.TPlo  -KPIC -DPIC
> -----
>
> Hence, the output is named "one.o" instead of "libone_la-one.lo", and the
> Automake-generated Makefile gets confused because the expected file does
> not exist.  "make all" then fails and aborts.
>
> The solution is to remove this "chmod -w ." from the libtool.m4 file
> before the test checking for -c/-o support.  There's a lengthy comment
> before this chmod in the m4 macro (CVS checkout dated 11/5/2003,
> m4/libtool.m4, starting on line 960):
>
> -----
>    # According to Tom Tromey, Ian Lance Taylor reported there are C compilers
>    # that will create temporary files in the current directory regardless of
>    # the output directory.  Thus, making CWD read-only will cause this test
>    # to fail, enabling locking or at least warning the user not to do parallel
>    # builds.
>    chmod -w .
> -----
>
> This doesn't seem to have anything to do with whether the compiler
> supports -c and -o simultaneously.  Checking CVS records, it seems that
> this chmod was added back when libtool.m4 was in the top-level directory,
> at v1.101 (on 6 Sep 2000).  The commit log message doesn't mention this
> chmod at all, but the diff between v1.100 and v1.101 was pretty huge -- it
> looks like it was some kind of major change.
>
> I'm not entirely sure why this code was introduced, but if it was part of
> a major change like this, it could have slipped in accidentally and
> remained unnoticed until now.
>
> Regardless, although I'm not privy to the history or the reason why the
> chomod is there, I do not think that removing the chmod will have any
> unintended side-effects.  Removing it should be pretty simple and should
> allow libtool to correctly determine that icc supports -c and -o together.
>
> Thanks.
>
>

-- 
{+} Jeff Squyres
{+} address@hidden
{+} http://www.lam-mpi.org/