Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O (fwd)

[Alexandre Oliva]

On Mar 11, 2004, Bob Friesenhahn <address@hidden> wrote:

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

The failure to rename the object file to the name requested by the
user.

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

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

'fraid it's been a while, but I remember having run into such
compilers back when I had access to 10+ different platforms.  If I had
to guess, I'd say it was probably Ultrix that displayed the problem.

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

That's exactly the purpose of the locking feature.  Libtool creates a
lock file in .libs that prevents any other libtool from running a
compiler to create a file with the same name as the output object file
of the current compilation in the current directory.  This is what you
should see for cases in which the chmod -w . test failed:

% libtool --mode=compile $CC -c .../src/foo.c -o build/foo.lo
$CC -c .../src/foo.c
mv foo.o build/foo.o

there is code that is supposed to do the mv.  Why it's not triggering
and doing what it should is the problem we have.

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