[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compile problem
From: |
Gary V. Vaughan |
Subject: |
Re: compile problem |
Date: |
Tue, 21 Sep 2004 12:04:46 +0100 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040913) |
Hallo!
Ralf Wildenhues wrote:
> Alexandre Duret-Lutz writes:
>
>>>>> "Gary" == Gary V Vaughan <address@hidden> 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 ())_. address@hidden,gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
- Re: compile problem, (continued)
- Re: compile problem, Gary V . Vaughan, 2004/09/07
- Re: compile problem, Alexandre Duret-Lutz, 2004/09/08
- Re: compile problem, Gary V. Vaughan, 2004/09/10
- Re: compile problem, Bob Friesenhahn, 2004/09/10
- Re: compile problem, Gary V. Vaughan, 2004/09/10
- Re: compile problem, Bob Friesenhahn, 2004/09/10
- Re: compile problem, Alexandre Duret-Lutz, 2004/09/20
- Re: compile problem, Gary V. Vaughan, 2004/09/21
- Re: compile problem, Alexandre Duret-Lutz, 2004/09/20
- Re: compile problem, Ralf Wildenhues, 2004/09/20
- Re: compile problem,
Gary V. Vaughan <=
Re: compile problem, Gary V . Vaughan, 2004/09/08