* Interesting Makefile race condition ...
@ 2002-06-13 13:15 Ulrich Weigand
2002-06-13 13:21 ` DJ Delorie
0 siblings, 1 reply; 3+ messages in thread
From: Ulrich Weigand @ 2002-06-13 13:15 UTC (permalink / raw)
To: gcc
Hello,
I've just noticed some weird behaviour probably caused by a Makefile
race condition: I'd been experimenting with enabling multilibs on
s390, but simply doing a 'make -j6' would not build the multilibs.
However, after subsequently removing the stmp-multilib marker and
running make again, they suddenly *were* built.
What had apparently happened is that the rule building the libgcc.mk
file depends on '$(GCC_FOR_TARGET) --print-multi-lib' doing the right
thing. However, when running a parallel make, it can happen that
this command is being run *before* the new specs file is created.
This means that the newly build xgcc will look in the *install* directory
for a specs file, and if it finds one there from a previous installation,
it will use that one! This of course still contains old settings ...
How should this be fixed? Maybe any Makefile target using
$(GCC_FOR_TARGET) should depend on specs as well as on xgcc?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Interesting Makefile race condition ...
2002-06-13 13:15 Interesting Makefile race condition Ulrich Weigand
@ 2002-06-13 13:21 ` DJ Delorie
0 siblings, 0 replies; 3+ messages in thread
From: DJ Delorie @ 2002-06-13 13:21 UTC (permalink / raw)
To: Ulrich.Weigand; +Cc: gcc
> How should this be fixed? Maybe any Makefile target using
> $(GCC_FOR_TARGET) should depend on specs as well as on xgcc?
That seems like an obvious fix to me.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Interesting Makefile race condition ...
@ 2002-06-14 7:53 Ulrich Weigand
0 siblings, 0 replies; 3+ messages in thread
From: Ulrich Weigand @ 2002-06-14 7:53 UTC (permalink / raw)
To: DJ Delorie; +Cc: gcc, gcc-patches
>DJ Delorie wrote:
>
>> How should this be fixed? Maybe any Makefile target using
>> $(GCC_FOR_TARGET) should depend on specs as well as on xgcc?
>
>That seems like an obvious fix to me.
Actually it looks like all other targets using $(GCC_FOR_TARGET)
already depend on specs, it is just missing for libgcc.mk.
So I committed the following patch as obvious. Bootstrapped on
s390-ibm-linux.
ChangeLog:
* Makefile.in (libgcc.mk): Depend on specs.
Index: gcc/Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.899
diff -c -p -r1.899 Makefile.in
*** gcc/Makefile.in 11 Jun 2002 20:06:04 -0000 1.899
--- gcc/Makefile.in 14 Jun 2002 13:57:05 -0000
*************** xlimits.h: glimits.h limitx.h limity.h
*** 994,1000 ****
LIB2ADD = $(LIB2FUNCS_EXTRA)
LIB2ADD_ST = $(LIB2FUNCS_STATIC_EXTRA)
! libgcc.mk: config.status Makefile mklibgcc $(LIB2ADD) $(LIB2ADD_ST) xgcc
$(exeext)
objext='$(objext)' \
LIB1ASMFUNCS='$(LIB1ASMFUNCS)' \
LIB2FUNCS_1='$(LIB2FUNCS_1)' \
--- 994,1000 ----
LIB2ADD = $(LIB2FUNCS_EXTRA)
LIB2ADD_ST = $(LIB2FUNCS_STATIC_EXTRA)
! libgcc.mk: config.status Makefile mklibgcc $(LIB2ADD) $(LIB2ADD_ST) xgcc
$(exeext) specs
objext='$(objext)' \
LIB1ASMFUNCS='$(LIB1ASMFUNCS)' \
LIB2FUNCS_1='$(LIB2FUNCS_1)' \
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-06-14 14:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-13 13:15 Interesting Makefile race condition Ulrich Weigand
2002-06-13 13:21 ` DJ Delorie
2002-06-14 7:53 Ulrich Weigand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).