native cc re-used after 3-stage now

H . J . Lu hjl@valinux.com
Mon Jun 12 08:54:00 GMT 2000


On Mon, Jun 12, 2000 at 02:55:54PM +0200, Toon Moene wrote:
> H . J . Lu wrote:
> 
> > Thanks for taking it up. In fact, you don't need parallel build on
> > a SMP machine to see the bug. Since there are no dependencies on
> > s-libi77, s-libf77, s-libu77 and s-libe77, with "make -j 100000" in
> > libf2c, GNU make will start to build s-libi77, s-libf77, s-libu77 and
> > s-libe77 at the same time along with other targets. Since there are
> > no rules for them, the build will fail.
> 
> Well, the build will fail if s-lib[ifu]77 are *absent*, because there
> are no rules to build them.  They are supposed to be present when you
> hit the target (from .../egcs/libf2c/Makefile.in):
> 
> $(LIBG2C): s-libi77 s-libf77 s-libu77 s-libe77
> 
> because the sequence of events is as follows:
> 
> all: all-unilib
>         $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO="all-unilib"
> 
> all-unilib: i77 f77 u77 s-libe77
>         $(MAKE) $(FLAGS_TO_PASS) $(LIBG2C)
> 
> i77:
>         cd libI77; $(MAKE) $(FLAGS_TO_PASS) all
> 
> f77:
>         cd libF77; $(MAKE) $(FLAGS_TO_PASS) all
> 
> u77:
>         cd libU77; $(MAKE) $(FLAGS_TO_PASS) all
> 
> s-libe77: f2cext.c
> 	blah...blah...blah
> 
> and it is the responsibility of targets [ifu]77 to generate the stamp
> files s-lib[ifu]77.
> 
> So by the time $MAKE ... $(LIBG2C) is called, [ifu]77 and s-libe77 have
> been satisfied, which means that s-lib[ifu]77 and s-libe77 should be
> present.
> 

You are right and I cannot reproduce it myself. I will keep an eye
on it.

H.J.


More information about the Gcc mailing list