No clue on how to fix. build.log attached
err, build.log is too large to attach. http://dev.gentoo.org/~darkside/tmp/bug299905/build.log
Maybe the problem is with that line: * Running autoheader ... [ !! ]
if you just move to the workdir and run make (without -j8 -l10) does it fail on the same thing?
Thanks to grobian's suggestion, I recompiled gcc with EXTRA_ECONF="--disable-tls" and then I was able to compile xulrunner again. @toolchain: Could use your expertise here. Is there anything that can be done here to fix it so others wouldn't run into the problem? Maybe USE=tls for gcc or some check in an eclass? Here is my glibc version: %% /lib/libc.so.6 GNU C Library stable release version 2.3.4, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.4.6 20060404 (Red Hat 3.4.6-3). Compiled on a Linux 2.4.20 system on 2007-01-31. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton GNU Libidn by Simon Josefsson libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. Thanks for some/any help.
Created attachment 215729 [details] build.log.bz2 post logs to bugs ... dont link to them
that doesnt really work. you're forcing a chicken & egg scenario that cannot be broken. in order to build glibc w/tls, you need a gcc w/tls. gcc does not need a glibc w/tls, only an assembler w/tls. so gcc is not broken here as it isnt misdetecting anything -- your assembler probably supports TLS. adding a USE flag is a hack that doesnt really fix packages. the referenced gcc bug report is about the C++ library being broken. your build log doesnt show that -- it shows xulrunner being broken. sounds like xulrunner its tls configure check is incomplete. fix that instead. if you just submit a bug report upstream with xulrunner, you can use the tc-has-tls function from toolchain-funcs.eclass in the ebuild in the mean time.
Created attachment 216101 [details] configure-diff.txt between 1.9.1.3 (last known working) and 1.9.1.6 (first known to fail) As requested: 22:06 <Anarchy> if you would get me a diff between configure there and in .6 and we will see what we can do to help you out. 22:08 <darkside_> what do you mean? the output or the configure script? or? 22:08 <Anarchy> diff of configure script themselves. 22:08 <darkside_> ok, i could do that There is a tls check in the first hunk towards the top of the file that may be the culprit?
if 1.9.1.3 didnt really support TLS, then a diff of the configure script isnt really useful. the sample code might not fully exercise the TLS aspects of the toolchain. there are tricks gcc can do to optimize TLS accesses and avoid expensive things like execute helper kernel/C library functions (like __tls_get_addr on x86). this is why i wrote the tc-has-tls function. try running it on your old glibc host and make sure that: tc-has-tls -s # works tc-has-tls -c # works tc-has-tls -l # fails tc-has-tls # fails
(In reply to comment #8) > if 1.9.1.3 didnt really support TLS, then a diff of the configure script isnt > really useful. Oh, ok. That makes sense. > > the sample code might not fully exercise the TLS aspects of the toolchain. > there are tricks gcc can do to optimize TLS accesses and avoid expensive things > like execute helper kernel/C library functions (like __tls_get_addr on x86). Thanks for explaining. > > this is why i wrote the tc-has-tls function. try running it on your old glibc > host and make sure that: > tc-has-tls -s # works > tc-has-tls -c # works > tc-has-tls -l # fails > tc-has-tls # fails Confirmed. $? = 0 on the first two and 1 on the last two. If I am following, this *proves* a broken tls check in xulrunner? (what you said in comment #6)
i wouldnt say "broken" per-say, more "incomplete". feel free to take the snippet i wrote in toolchain-funcs.eclass and get it integrated upstream w/xulrunner with whatever license they like.
Thank you Mike, removing toolchain@g.o from the bug. Jory, I appreciate that there are higher priorities. I don't feel comfortable taking this issue upstream myself because I'd be talking about stuff that I don't know about. Maybe something like this[1] can get added to gentoo-x86 when time allows. (verified to workaround the issue on my host) Thanks. [1]: http://overlays.gentoo.org/proj/alt/changeset/57072
(In reply to comment #11) > Thank you Mike, removing toolchain@g.o from the bug. > > Jory, I appreciate that there are higher priorities. I don't feel comfortable > taking this issue upstream myself because I'd be talking about stuff that I > don't know about. Maybe something like this[1] can get added to gentoo-x86 when > time allows. (verified to workaround the issue on my host) > > Thanks. > This has been added to official overlay in version 1.9.2.8. > [1]: http://overlays.gentoo.org/proj/alt/changeset/57072 >
