Re: compile problem

["Gary V. Vaughan" <gary at gnu dot org>]

Hallo!

Ralf Wildenhues wrote:
> Alexandre Duret-Lutz writes:
> 
>>>>> "Gary" == Gary V Vaughan <gary@gnu.org> writes:
>> because AM_PROG_CC_C_O horribly
>> overwrites CC, it's not clear to me whether
>>
>> AM_PROG_CC_C_O
>> LT_INIT
>>
>> is equivalent to 
>>
>> LT_INIT
>> AM_PROG_CC_C_O
>>
>> It looks like Libtool's `-c -o' check would not give the same
>> answer.  I haven't dug all this; I think Ralf W sent some mail
>> about it, but I haven't flushed all my mails yet.

Agreed.  From earlier conversation if would seem preferable to have
AM_PROG_CC_C_O called first. Can't that be solved with a call to
AC_BEFORE in AM_PROG_CC_C_O?

> Note that my conclusions were partly wrong because of several reasons:
> - I tried with the wrong order of AC_PROG_CC and AM_PROG_CC_C_O
> (this is fortunately solved now)
> - My first tests were done overwriting config.cache variables in a
> non-safe manner: Whether Libtool's _C_O test succeeds or fails depends
> partly on whether AM_PROG_CC_C_O was run before (and with what output).
> More complicating:  Right now the tests do not use the same method to
> check, which means (and yes, this actually happens!) that either one can
> fail or succeed, and you have to actually look at all the possibilities.
> I especially don't like the Libtool check because it greps for compiler
> warnings instead of checking for the right output file.  Warnings could
> have very different cause.

Agreed again.  _LT_COMPILER_C_O should probably be rewritten, and modelled
after AC_PROG_CC_C_O.  That done, we could also optimize it to look at the
cache vars rather than rerunning the tests for compilers that have already
been checked.

> But another issue I did find out:  While Automake makes sure that all
> automake'n Makefiles use `compile' in the case of a bad compiler,
> Libtool has no way of making sure all compilations of `foo.c' are
> employed using `libtool'.  This makes it impossible for libtool to guard
> against
> # This is part of a non-Automake Makefile
> libfoo.la: foo.lo
> bar: foo.o

I don't follow... if Automake isn't involved, the user has to write their own
inference rule for .lo don't they?

>> I agree it would be better to set down a common lock scheme,
>> although that really should not hold any release.
>  
> In this case you *must* make sure that whenever Automake detects a bad
> compiler `C', Libtool detects `compile C' as a good compiler, in order
> to prevent deadlock.

Sharing cachevars should take care of that.

Cheers,
	Gary.
-- 
Gary V. Vaughan      ())_.  gary@{lilith.warpmail.net,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature