bug-libtool
[Top][All Lists]
Advanced

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

Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O


From: Jeff Squyres
Subject: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O
Date: Tue, 16 Dec 2003 07:26:15 -0500 (EST)

Greetings.

Any idea when the anonymous CVS repository at subversions.gnu.org will be
back?  It's been non-responsive for at least the last week.

I haven't heard anything back about my bug report (original mail included
below), so I took the liberty of providing a patch for my suggested fix
(as of the CVS HEAD on 3 Dec 2003).  Pardon mail client line wrap...

-----
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.20
diff -u -r1.20 libtool.m4
--- m4/libtool.m4       14 Nov 2003 11:12:21 -0000      1.20
+++ m4/libtool.m4       14 Nov 2003 13:17:47 -0000
@@ -976,13 +976,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/




reply via email to

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