Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O (fwd)

[Alexandre Oliva]

On Jan 22, 2004, Bob Friesenhahn <address@hidden> wrote:

> Sorry for the long wait.  My CVS access is working again.  This patch
> has been applied to both CVS head and branch-1-5.

Err...   I think it should be reverted.  It's just hiding a different
bug, and not fixing anything.

> On Wed, 21 Jan 2004, Jeff Squyres wrote:

>> It's time for my periodic ping on getting rid of the "chmod -w ." in the
>> AC_LIBTOOL_PROG_CC_C_O test.  :-)

The purpose of chmod -w . is to make sure the compiler does not write
to pwd.  If it does, odds are that, if you compile:

$CC -c foo.c -o dir1/foo.o
$CC -c foo.c -o dir2/foo.o

and these two commands happen to run at the same time, one may step on
the other's toes and things break at random.  That's bad.

Even if the compiler safely handles temp file creation, it shouldn't
hurt that we decide to use locking for such a compiler.

The actual bug is described here:

>> > 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):

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

When libtool removes the -o from the command line, it should rename
the output file after compiling without -o.  This is the bug you
should try to fix instead.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}