Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 291488 - sys-devel/binutils-2.20.51.0.1 build failure in bootstrap
Summary: sys-devel/binutils-2.20.51.0.1 build failure in bootstrap
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: x86 Solaris
: High normal with 1 vote (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
: 324751 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-01 21:34 UTC by Brad Ackerman
Modified: 2010-12-24 08:27 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Full output from attempt to compile current binutils (binutils.out,351.67 KB, text/plain)
2009-11-01 21:35 UTC, Brad Ackerman
Details
Patch for bootstrap-prefix.sh which appears to resolve this bug (bootstrap-prefix.sh.patch,2.15 KB, patch)
2010-06-22 15:28 UTC, Chris Engelhart
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Ackerman 2009-11-01 21:34:18 UTC
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
Comment 1 Brad Ackerman 2009-11-01 21:35:58 UTC
Created attachment 208987 [details]
Full output from attempt to compile current binutils
Comment 2 Fabian Groffen gentoo-dev 2009-11-11 14:53:57 UTC
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?
Comment 3 Brad Ackerman 2009-11-28 22:17:44 UTC
It's where you get to "emerge --oneshot --nodeps binutils" in listing 1.8.
Comment 4 Brad Ackerman 2010-03-27 15:38:07 UTC
Still present in sys-devel/binutils-2.20.51.0.4. on a pretty much fresh install of OpenSolaris 2009.06.
Comment 5 thomas weidner 2010-04-05 20:53:35 UTC
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)
Comment 6 Chris Engelhart 2010-06-21 17:30:50 UTC
*** Bug 324751 has been marked as a duplicate of this bug. ***
Comment 7 Chris Engelhart 2010-06-21 17:33:48 UTC
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?
Comment 8 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-06-21 17:47:57 UTC
(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?
Comment 9 Chris Engelhart 2010-06-21 21:33:34 UTC
(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?
Comment 10 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-06-21 22:10:42 UTC
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
Comment 11 Chris Engelhart 2010-06-22 15:28:44 UTC
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.
Comment 12 Chris Engelhart 2010-06-22 18:50:27 UTC
(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.
Comment 13 Fabian Groffen gentoo-dev 2010-06-22 21:55:06 UTC
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.
Comment 14 Fabian Groffen gentoo-dev 2010-12-24 08:27:31 UTC
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/