Summary: | sys-devel/binutils-2.20.51.0.1 build failure in bootstrap | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Brad Ackerman <brad> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, thomas001le |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Solaris | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Full output from attempt to compile current binutils
Patch for bootstrap-prefix.sh which appears to resolve this bug |
Description
Brad Ackerman
2009-11-01 21:34:18 UTC
Created attachment 208987 [details]
Full output from attempt to compile current binutils
Hmmm, I need to see if I can compile it on a 64-bits x64 solaris prefix, if it does then it's some bootstrap problem. What step is this at? It's where you get to "emerge --oneshot --nodeps binutils" in listing 1.8. Still present in sys-devel/binutils-2.20.51.0.4. on a pretty much fresh install of OpenSolaris 2009.06. The problem seems to be the -L/usr/sfw/lib/64 flag. the linker searches for libiberty first in this location before the directory where binutils is built. after having removed -L/usr/sfw/lib/64 from the profile defaults binutils built fine. (though this may break other stuff) *** Bug 324751 has been marked as a duplicate of this bug. *** I see this is nothing new. As in the bug I just realized was a duplicate, this is an issue with Solaris 10 as well. Any chance of the fix described by Thomas being merged in? Is Gentoo Prefix still being actively mantained? (In reply to comment #7) > I see this is nothing new. As in the bug I just realized was a duplicate, this > is an issue with Solaris 10 as well. Any chance of the fix described by Thomas > being merged in? Is Gentoo Prefix still being actively mantained? > Yes, more active than other projects actually. Except you are at the mercy of the devs that have your hw platform. ;) http://www.gentoo.org/proj/en/gentoo-alt/prefix/#doc_chap3 Sometimes available time gets stretched thin, thanks for your patience and sorry for your troubles. Let's try to come up with a working solution similar to comment #5. One possible testing point is to modify bootstrap-prefix.sh to not set the linker flag(s) (about line 187). Re-bootstrap and see how far it gets and if there are any issues. Volunteers? (In reply to comment #8) > Let's try to come up with a working solution similar to comment #5. One > possible testing point is to modify bootstrap-prefix.sh to not set the linker > flag(s) (about line 187). Re-bootstrap and see how far it gets and if there are > any issues. Volunteers? > I'm willing to try. Will hopefully be able to give you results in about 24-48 hours. BTW, I'm not sure if this is the right place for this, but I noticed there are a few more devs for sparc than sparc64. I am a professional Solaris admin and I haven't seen any 32-bit systems in a long time. Of course Sun has done a good job keeping everything compatible, so you can still use 32 bit software, and Solaris still supports them. But are the developers really on such old hardware, or is there a reason to be using sparc instead of sparc64? Off-topic: It is generally easier to maintain a 32bit prefix than 64bit. (Because I don't run into problems like this :) Beyond that, there is more testing in the 32bit prefix because it is the default which means wider audience and more support[1]. All of my sparc hardware is 64bit, I just can't commit to using/supporting a 64bit prefix installation. (I've never even seen a 32bit only sparc system) :) [1]: http://stats.prefix.freens.org/keywords-packages.png Created attachment 236251 [details, diff] Patch for bootstrap-prefix.sh which appears to resolve this bug This patch removes all the linking to /usr/sfw/lib/64 from the following target OS/Arch Solaris 9 / sparc64 Solaris 10 / sparc64 Solaris 10 / amd64 OpenSolaris / sparc64 OpenSolaris / amd64 This appears to resolve bug #291488, but it may break something else. It has not been tested except on Solaris10/sparc64. (In reply to comment #11) > Created an attachment (id=236251) [details] > Patch for bootstrap-prefix.sh which appears to resolve this bug > This appears to resolve bug #291488, but it may break something else. It has > not been tested except on Solaris10/sparc64. > Hmm well I was able to get through everything up to and including binutils, but gcc isn't compiling now: $ emerge --oneshot --nodeps "=gcc-4.2*" ... sparcv9-sun-solaris2.10-ar rc ./libiberty.a \ /strsignal.o ./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./asprintf.o ./mempcpy.o ./mkstemps.o ./sigsetmask.o ./stpcpy.o ./stpncpy.o ./strndup.o ./strverscmp.o ./vasprintf.o ld.so.1: ar: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 ... I could be wrong but looks like this was caused by the "fix." There is a: /usr/sfw/lib/64/libgcc_s.so.1: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped and I'm assuming that it otherwise would have been used. (I'm honestly not sure where it's coming up with this 32-bit one though, because the bootstrap doesn't mention /usr/sfw/lib at all, in either sparc or sparc64.) Not sure if this counts as a new bug, or if it's really not a bug because was caused by the "fix" to this one. And btw thanks darkside for answering my question. Maybe I'll install a 32-bit prefix in another directory if this doesn't get working soon. I think we've seen this before. It's because binutils puts the LDFLAGS before it's own -L flags making it find the wrong libiberty.a from /usr/sfw/lib/64 instead of its own. Perhaps later binutils are just broken in this regard. I fixed this some while ago: # we need this, or binutils can't link, can't add it to -L, # since then binutils breaks on finding an old libiberty.a # from there instead of its own cp /usr/sfw/lib/64/libgcc_s.so.1 "${ROOT}"/tmp/usr/lib/ |