[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compile problem
From: |
Ralf Wildenhues |
Subject: |
Re: compile problem |
Date: |
Mon, 20 Sep 2004 18:03:53 +0200 |
Alexandre Duret-Lutz writes:
"Gary" == Gary V Vaughan <address@hidden> writes:
Gary> But for a project built with `make -j', we still need AM_PROG_CC_C_O
Gary> and _LT_COMPILER_C_O to understand each others' locks :-(
Seems so. I thought it was not needed because when
AM_PROG_CC_C_O decides `compile' is required, it is also used
when compiling libtool objects. However perhaps I was wrong,
because `compile' does something only for *.o and *.obj files,
it is a no-op for *.lo files.
This is one problem (one I even haven't noticed yet).
Maybe we need to tell AM_PROG_CC_C_O about *.lo files.
To makes matter worse, 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.
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.
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 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.
Regards,
Ralf
- Re: compile problem, Alexandre Duret-Lutz, 2004/09/07
- 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 <=
- Re: compile problem, Gary V. Vaughan, 2004/09/21
Re: compile problem, Gary V . Vaughan, 2004/09/08