Execution of "emerge --oneshot --nodeps binutils" in the Solaris x86_64 bootstrap procedure fails in bfd. emerge of previous version 2.19.1-r01 works as expected. Reproducible: Always Steps to Reproduce: 1. Follow the Solaris bootstrap directions as in the docs with CHOST x86_64-pc-solaris2.10. 2. When you get to binutils, note that it fails. Actual Results: ec.o .libs/binary.o .libs/tekhex.o .libs/ihex.o .libs/stabs.o .libs/stab-syms.o .libs/merge.o .libs/dwarf2.o .libs/simple.o .libs/comprlib/64 -L/opt/gentoo/usr/lib -L/opt/gentoo/lib -L/usr/sfw/lib/64 -L/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20.51.0.1/work/bulibtool: link: gcc -m64 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libbfd-2.20.51.0.1.20090905.so -o .libs/libbfd-2.20.51.0.1.20090905.so .libs/archive.o .libs/archures.o .libs/bfd.o .libs/bfdio.o .libs/bfdwin.o .libs/cache.o .libs/coffgen.o .libs/corefile.o .libs/format.o . libs/init.o .libs/libbfd.o .libs/opncls.o .libs/reloc.o .libs/section.o .libs/syms.o .libs/targets.o .libs/hash.o .libs/linker.o .libs/srec.o .libs/binary.o .libs/tekhex.o .libs/ihex.o .libs/stabs.o .libs/stab-syms.o .libs/merge.o .libs/dwarf2.o .libs/simple.o .libs/c ompress.o .libs/verilog.o .libs/elf32-i386.o .libs/elf-ifunc.o .libs/elf-vxworks.o .libs/elf32.o .libs/elf.o .libs/elflink.o .libs/elf-attrs.o .libs/elf-strtab.o .libs/elf-eh-frame.o .libs/dwarf1.o .libs/elf64-x86-64.o .libs/elf64.o .libs/coff-i386.o .libs/cofflink.o .libs/elf64-gen.o .libs/elf32-gen.o .libs/cpu-i386.o .libs/cpu-l1om.o .libs/archive64.o -R/opt/gentoo/usr/lib -R/opt/gentoo/lib -R/usr/sfw/lib/64 -L/opt/gentoo/usr/lib -L/opt/gentoo/lib -L/usr/sfw/lib/64 -L/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20.51.0.1/w ork/build/bfd/../libiberty/pic -liberty -lm -lz -lc -m64 Text relocation remains referenced against symbol offset in file <unknown> 0x20 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x38 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x50 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x80 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0xa8 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0xd0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0xf8 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x140 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x158 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x190 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x1c0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x1d8 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x208 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x240 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x278 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x2b0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x2e0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x320 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x338 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x368 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x3b0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x3f0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x408 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x440 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x478 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) <unknown> 0x4b0 /usr/sfw/lib/64/libiberty.a(cplus-dem.o) [...more of this...] ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[4]: *** [libbfd.la] Error 1 make[4]: Leaving directory `/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20. 51.0.1/work/build/bfd' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20. 51.0.1/work/build/bfd' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20. 51.0.1/work/build/bfd' make[1]: *** [all-bfd] Error 2 make[1]: Leaving directory `/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20. 51.0.1/work/build' make: *** [all] Error 2 * ERROR: sys-devel/binutils-2.20.51.0.1 failed: * emake failed * * Call stack: * ebuild.sh: 51: <call src_compile> * environment:3351: <call toolchain-binutils_src_compile> * environment:4014: emake all || die "emake failed"; * * If you need support, post the topmost build error, and the call stack if rele vant. >>> Failed to emerge sys-devel/binutils-2.20.51.0.1, Log file: >>> '/opt/gentoo/var/tmp/portage/sys-devel/binutils-2.20.51.0.1/temp/build.log' * Messages for package sys-devel/binutils-2.20.51.0.1: * Can't read /config.sub, skipping.. * Can't read /config.guess, skipping.. * ERROR: sys-devel/binutils-2.20.51.0.1 failed: * emake failed * * Call stack: * ebuild.sh: 51: <call src_compile> * environment:3351: <call toolchain-binutils_src_compile> * environment:4014: emake all || die "emake failed"; * * If you need support, post the topmost build error, and the call stack if rele vant. Expected Results: Should successfully build binutils. System is Solaris 10u8 (10/09) on x86_64 w/ dual-core Opteron and 8GB RAM. bash-3.00# emerge --info Portage 2.2.00.14200-prefix (prefix/sunos/solaris/5.10/x64, gcc-3.4.3, unavailable, 5.10 i86pc) ================================================================= System uname: Solaris-2.10-i86pc-i386-32bit-ELF Timestamp of tree: Sat, 17 Oct 2009 21:58:52 +0000 app-shells/bash: 4.0_p33-r00.1 sys-devel/binutils: 2.19.1-r01.1 sys-devel/gcc-config: 1.4.1-r00.2 ACCEPT_KEYWORDS="~x64-solaris" CBUILD="x86_64-pc-solaris2.10" CFLAGS="" CHOST="x86_64-pc-solaris2.10" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CPPFLAGS="-I/opt/gentoo/usr/include" CXXFLAGS="" DISTDIR="/opt/gentoo/usr/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages nostrip parallel-fetch preserve-libs protect-owned sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="-L/opt/gentoo/usr/lib -R/opt/gentoo/usr/lib -L/opt/gentoo/lib -R/opt/gentoo/lib -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" PKGDIR="/opt/gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/opt/gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/opt/gentoo/var/tmp" PORTDIR="/opt/gentoo/usr/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="cracklib modules ncurses prefix readline x64-solaris zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="SunOS" INPUT_DEVICES="keyboard mouse" KERNEL="SunOS" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
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/