Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O

[Jeff Squyres]

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/