Created attachment 337100 [details] build log This is strange, I have gcc:4.6 now: alpha ~ # gcc -v Using built-in specs. COLLECT_GCC=/usr/alpha-unknown-linux-gnu/gcc-bin/4.6.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/alpha-unknown-linux-gnu/4.6.3/lto-wrapper Target: alpha-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/alpha-unknown-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.6.3/include/g++-v4 --host=alpha-unknown-linux-gnu --build=alpha-unknown-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/alpha-unknown-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.11, pie-0.5.2' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2) But I'm unable to recompile it.
Portage 2.1.11.31 (default/linux/alpha/10.0, gcc-4.6.3, glibc-2.15-r3, 3.4.0-gentoo alpha) ================================================================= System uname: Linux-3.4.0-gentoo-alpha-EV68AL-with-gentoo-2.1 Timestamp of tree: Mon, 28 Jan 2013 01:45:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3-r1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="alpha" ACCEPT_LICENSE="*" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -pipe -O2 -mcpu=ev4" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-mieee -pipe -O2 -mcpu=ev4" DISTDIR="/usr/portage/distfiles/" EMERGE_DEFAULT_OPTS="--with-bdeps y --keep-going y -1" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alpha apng berkdb bzip2 cli cracklib crypt cxx dlz dri fortran gdbm gpm iconv ipv6 modules mudflap ncurses nls nptl openmp pam pcre readline session ssl tcpd unicode zlib" ALSA_CARDS="ali5451 als4000 bt87x ca0106 cmipci emu10k1 ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 maestro3 trident usb-audio via82xx ymfpci" 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3 php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" USE_PYTHON="2.7 3.2"
Can you build it using 4.5?
(In reply to comment #2) > Can you build it using 4.5? Now I haven't 4.5 and with 4.6 I'm unable to build 4.5. Same error
According to the alpha gcc maintainer, we shouldn't bother with LTO and gcc-4.6. Can we disable it on alpha? For 4.5 there's the USE-flag but for 4.6 its forced.
Can you see if this works? --- toolchain.eclass 16 Mar 2013 05:44:49 -0000 1.570 +++ toolchain.eclass 22 Mar 2013 04:39:40 -0000 @@ -1106,7 +1106,7 @@ # users to enable that option, and pull in the additional library. In 4.6, # the dependency is no longer required. if tc_version_is_at_least "4.6" ; then - confgcc+=" --enable-lto" + : elif tc_version_is_at_least "4.5" ; then confgcc+=" $(use_enable lto)" fi Maybe we can stop forcing the option and let it use the default for the arch.
(In reply to comment #5) > Can you see if this works? > >[snip] Negative, it doesn't work, it still tries to build lto. This is upstream link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47230 Either we apply Uros' patch, considering the workaround is being used in more packages, or we disable lto building on alpha. Thanks
http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/gcc/4.6.4/gentoo/27_all_alpha-no-relax.patch?rev=1.1&view=markup
Fixed in 4.6.4.
Created attachment 346600 [details] build log
(In reply to comment #8) > Fixed in 4.6.4. not fixed
(In reply to comment #10) > (In reply to comment #8) > > Fixed in 4.6.4. > > not fixed I don't want to misunderstand...I should be able to compile 4.6.4 with 4.6.3 ?
I was afraid of that, since this error doesn't match the one in the upstream PR.
(In reply to comment #12) > I was afraid of that, since this error doesn't match the one in the upstream > PR. Right...my fault for not testing Uros' patch with lto... So...i suggest disabling lto for alpha on gcc-4.6 :)
Blargh. I'd rather have it fixed in the linker. Does 4.7 fail the same way? ie. will I be adding an lto USE flag to every version?
Odd I don't see -Wl,--no-relax in that log. Can you try manually adding it to LDFLAGS?
Nevermind we don't respect LDFLAGS. >_<
Try STAGE1_LDFLAGS.
lto flag added. mask away.
All right, since you said we don't respect LDFLAGS provided from gcc itself(ie, we respect user's LDFLAGS), i suggest appending "-Wl,--no-relax" to LDFLAGS when building gcc on alpha. After that you can remove the lto USE-flag if you want... Sorry for taking so long to answer and for making you play with the lto USE-flag which wasn't needed after all.
No problem, but I need to know exactly what does and doesn't work. Does building with USE="-lto" work? Does building with LDFLAGS="-Wl,-no-relax" work or is it STAGE1_LDFLAGS="-Wl,-no-relax"? Whichever of those it is, does it work with USE="lto"? And please test by building gcc twice to see if it can compile itself.
(In reply to Ryan Hill from comment #20) > No problem, but I need to know exactly what does and doesn't work. Does > building with USE="-lto" work? Does building with LDFLAGS="-Wl,-no-relax" > work or is it STAGE1_LDFLAGS="-Wl,-no-relax"? Whichever of those it is, > does it work with USE="lto"? And please test by building gcc twice to see > if it can compile itself. Fair enough. The process i've done to test it: 1. Build gcc-4.6.3 2. Change compiler to gcc-4.6.3 3. Rebuild gcc-4.6.3 What i've tested: - Normal build fails - Building without lto fails - Building with lto and STAGE1_LDFLAGS="-Wl,--no-relax" fails - Building with lto and LDFLAGS="-Wl,--no-relax" works All of the failures happen when rebuilding gcc-4.6.3 with gcc-4.6.3. Thanks
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/toolchain.eclass?r1=1.597&r2=1.598 Hopefully this is fixed now. Sorry about the wait.
Sorry for reopening. This fixes current stable but in the future the issue would reappear, as you applied the workaround for 4.6 only. Building gcc-4.7 with gcc-4.6 fails, as does building gcc-4.5 with gcc-4.6. Also building 4.7.3 with 4.7.3 fails as well. I would suggest to add this workaround to all versions of gcc. Thanks
(In reply to Raúl Porcel from comment #23) > Sorry for reopening. > This fixes current stable but in the future the issue would reappear, as you > applied the workaround for 4.6 only. Building gcc-4.7 with gcc-4.6 fails, as > does building gcc-4.5 with gcc-4.6. > > Also building 4.7.3 with 4.7.3 fails as well. I would suggest to add this > workaround to all versions of gcc. I thought that's what I did for bug #481006.
Oh I bet it's because LDFLAGS isn't passed to stage 2/3. I thought building the first stage with -Wl,--no-relax was enough to let it build later stages. I forgot we applied the patch in comment #7 for 4.6. Gives me an excuse to fix bug #337788 anyways.
I've built: - gcc-4.8.1-r1 with gcc-4.8.0 - gcc-4.7.3-r1 with gcc-4.8.1-r1 - gcc-4.7.3-r1 with gcc-4.7.3-r1 and they all succeeded. Is there something else I should be testing?
4.7 with 4.6 I guess, but I wouldn't expect that to be any different than 4.7 with 4.7. Were you building natively or a cross-compiler? The latter should work now, it's bootstrapping that's broken. BTW, is this with or without the LDFLAGS patch from bug #337788? I'd like to get that patch in regardless so if it doesn't break anything that's good enough for me. Thanks for the testing!
(In reply to Ryan Hill from comment #27) > 4.7 with 4.6 I guess, but I wouldn't expect that to be any different than > 4.7 with 4.7. Were you building natively or a cross-compiler? The latter > should work now, it's bootstrapping that's broken. > > BTW, is this with or without the LDFLAGS patch from bug #337788? I'd like > to get that patch in regardless so if it doesn't break anything that's good > enough for me. > > Thanks for the testing! I was testing without the LDFLAGS patch (I wanted to make sure the LDFLAGS patch fixed what it was supposed to). I just built - gcc-4.6.4 with gcc-4.7.3-r1 - gcc-4.7.4-r1 with gcc-4.6.4 All succeeded. Now trying 4.6.4 with 4.6.4.
.... and - gcc-4.6.4 with gcc-4.6.4 succeeds. armin76?
(In reply to Matt Turner from comment #29) > .... and > > - gcc-4.6.4 with gcc-4.6.4 > > succeeds. > > armin76? Yeha, probably binutils-2.23 had something to do with this error dissapearing... we can close this as WORKSFORME or OBSOLETE, i think.
