Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O (fwd)

[Bob Friesenhahn]

On 11 Mar 2004, Alexandre Oliva wrote:

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

What bug is it hiding?

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

If indeed a compiler steps on its own toes, that would be indeed be a
bad thing and its vendor should be shot.  Since you seem to have
confidence that compilers which write to the current directory tend to
do that (as compared with compilers which write to the system
temporary file directory) can you identify one or more specific
compilers which exhibit this problem?

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

Apparently the previous implementation kept a compiler from being used
at all.

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

The test seems to assume that if a compiler writes files to the
current directory that the file written must have been the output
object file.  That is a wrong assumption since the compiler may
reasonably write temporary pre-processed source or assembly files to
the current directory.  As long as the files use non-conflicting
names, there is no problem.

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