------- Comment #35 from iains at gcc dot gnu dot org 2010-06-02 09:44 -------
(In reply to comment #34)
> > can you do me a favor?
> > (a) copy the config.{log,out} files.
> > (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> > .. I suspect a configure race condition - and would not be surprised if the
> > second attempt works...
> > (it's essential to re-do the configure - not just to re-try the bootstrap).
> > (c) if it works we can compare the config files and try and figure out where
> > the race is.
>
> I am not sure to understand what you ask me to do in (b):
>
> rm -r what?
>
> should I run 'reconfigure' in the building directory?
>
> Although I did not check that the failure is always due to the failing test
> spotted in comment #13, I am pretty confident that it is the case. A quick
> diagnostic is given in comment #3 of pr44304. I have seen the infamous
> "gcc_cv_have_tls=no" randomly at stage 2 or 3 and in libgomp or i386/libgomp.
>
(In reply to comment #34)
> > can you do me a favor?
> > (a) copy the config.{log,out} files.
> > (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> > .. I suspect a configure race condition - and would not be surprised if the
> > second attempt works...
> > (it's essential to re-do the configure - not just to re-try the bootstrap).
> > (c) if it works we can compare the config files and try and figure out where
> > the race is.
>
> I am not sure to understand what you ask me to do in (b):
>
> rm -r what?
your failed build.
> should I run 'reconfigure' in the building directory?
do a clean configure & bootstrap without updating the source tree.
If it is a marginal race condition, it is likely to succeed.
I guess the other proof is a non-j<n> bootstrap (but that takes longer to
prove).
I agree the tls variable is the likely culprit - perhaps there is a missing
dependency on building libgomp. I think that introduction of libgomp into all
stages is recent-ish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
