bug-libtool
[Top][All Lists]
Advanced

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

Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O (fwd)


From: Bob Friesenhahn
Subject: Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O (fwd)
Date: Wed, 21 Jan 2004 17:04:21 -0600 (CST)

Someone (Gary) signed me up to do this.  I have not gotten to this
task yet.  This will be a good test to see if my Savannah access works
now.

Bob

On Wed, 21 Jan 2004, Jeff Squyres wrote:

> Greetings.
>
> It's time for my periodic ping on getting rid of the "chmod -w ." in the
> AC_LIBTOOL_PROG_CC_C_O test.  :-)
>
> As of today's CVS (21 Jan), I see that it's still there.  Here's the patch
> to get rid of it:
>
> -----
> Index: m4/libtool.m4
> ===================================================================
> RCS  /cvsroot/libtool/libtool/m4/libtool.m4,v
> retrieving revision 1.33
> diff -u -r1.33 libtool.m4
> --- m4/libtool.m4       21 Jan 2004 14:38:54 -0000      1.33
> +++ m4/libtool.m4       21 Jan 2004 22:52:12 -0000
> @@ -1314,13 +1314,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.
> -----
>
> Original e-mail containing rationale is included below (although there
> have been more followups on this list about this topic as well).
>
> --
> {+} Jeff Squyres
> {+} address@hidden
> {+} http://www.lam-mpi.org/
>
>
> 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.
>
>
> _______________________________________________
> Bug-libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-libtool
>

======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen





reply via email to

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