Re: [PATCH 1.5] testsuite failures: missing AM_PROG_CC_C_O

[Ralf Wildenhues]

[ opening a can of worms ]

* Alexandre Duret-Lutz wrote on Fri, Sep 10, 2004 at 03:02:37PM CEST:
> >>> "Ralf" == Ralf Wildenhues <address@hidden> writes:
> 
> [...]
> 
>  Ralf> Now what happens?  Will `compile' be used? [*]
> 
> It depends where per-targets flags have been added: compile was
> used with your previous patch, it is not with the new one.

Actually, no.  I mistakenly added the AM_PROG_CC_C_O *before* the
AC_PROG_CC, which was happy to overwrite CC again (don't ask me why).
If added after, then yes, compile is used.

But then much more fun ensues because `compile' cannot sope with spaces
in arguments (like "-DPACKAGE_STRING=\"demo 1.0\"").  Bugreport with
patch to bug-automake is underway, this is a completely different topic.

>  Ralf> Because then, since the file will be compiled in two different ways 
> (one
>  Ralf> with Libtool and one without), AND since `compile' and `libtool' have
>  Ralf> different locking schemes, there is a potential for silent breakage in
>  Ralf> parallel builds, iff the compiler does not understand -c -o.
> 
> Presently when compile is used, it is hardcoded into CC, so it
> is also used with libtool.
> 
> [...]
> 
>  Ralf> [*] A quick test showed that in the demo/ example, `compile' will not 
> be
>  Ralf> used, even if ac_cv_compiler_c_o=no, because some macro overwrites CC
>  Ralf> within the configure run (and does not reset it).  Seems broken to me.
> 
> So it seems to me, although I'm not sure what your test is,
> and AFAICT this is not the variable used by A[CM]_PROG_CC_C_O.

Oh right, the variable name is different.  Sorry, I was not precise.
But the explanation for the brokenness is above, so that is a non-issue
(maybe document AM_PROG_CC_C_O to belong after AC_PROG_CC ...).


But back to my other, more relevant issue:  Basically, if an object is
compiled with libtool and without, there is NOT a race condition w.r.t
parallel builds, if the compiler does not understand -c -o.
If `compile' is used, as in
   ./libtool --mode=compile path/to/compile cc ...
then everything is fine, since libtool will detect the compiler
(named `path/to/compile cc') to work with -c -o, and compile will lock.
The non-libtool object will also use `compile' so everything is fine.


Now there is the issue remaining that AM_PROG_CC_C_O might detect the
compiler as working and Libtool not (this is the case with e.g., CC=icc
CFLAGS=-Wall, because any compilation warnings will cause the answer to
be no).  Then the non-libtool-compiled object and the libtool-compiled
one are not protected against each other.  Ok, let's treat this as a
icc problem, not a libtool problem.

For improved future googleability: the warning is

| a.c(1): remark #1418: external definition with no prior declaration
|   int some_variable = 0;
|       ^

and can be fixed by using CFLAGS='-W -wd1418'.
(No, prepending `extern int some_variable;' will cause another warning,
an extern variable not being defined in a header file).  I am aware that
is impossible to write a source which does not cause any compiler to
produce a warning.

Sorry for being so verbose, thank you for your attention,
Ralf