After upgrading to this version of the package, two of my systems were partially broken because the ebuild apparently failed to call binutils-config and update the profile, leaving me without the /usr/i686-pc-linux-gnu/binutils-bin/* files linked to their proper locations. Consequently, Portage was no longer able to install packages. It seems that the binutils binaries were moved in this release, necessitating a profile update. This was fixed by executing `binutils-config PROFILE`. See toolchain-binutils_pkg_postinst() in /usr/portage/eclass/toolchain-binutils.eclass Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-hardenednopie, glibc-2.3.4.20041102-r1, 2.6.10-hardened-r3 i686) ================================================================= System uname: 2.6.10-hardened-r3 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Mar 16 2005, 01:31:32)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.8.5-r3, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks noinfo sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 crypt cups gif hardened jpeg nls nptl nptlonly pam pcre perl pic pie png readline sse sse2 ssl tiff unicode zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
how were you able to get a /etc/env.d/binutils/config-${CTARGET} file and have a broken system ?
Here is a portion of the result of upgrading to this version of the package: --snip-- <<< sym /usr/bin/ld <<< sym /usr/bin/gprof <<< sym /usr/bin/c++filt <<< sym /usr/bin/as <<< sym /usr/bin/ar <<< sym /usr/bin/addr2line <<< dir /usr/share/doc/binutils-2.15.92.0.2-r1/opcodes <<< dir /usr/share/doc/binutils-2.15.92.0.2-r1/libiberty --snip-- <<< dir /usr/share/doc/binutils-2.15.92.0.2-r1 <<< dir /usr/i686-pc-linux-gnu/bin --- !empty dir /usr/share/man/man1 --- !empty dir /usr/share/man --snip-- As you can see, what it's unmerging would break the system. The above was taken from the end of the upgrade process, and since binutils-config was not called for whatever reason, the missing files were never recreated. To answer your question, I don't know. I wasn't monitoring the status of the merged files when I upgraded the package because I wasn't expecting it to break. I'll attach the file merging portion of the update.
Created attachment 55433 [details] binutils-file-log
no, those are supposed to be unmerged `binutils-config` replaces all of those files but for some reason, it was not executed on your system if you do `rm /etc/env.d/binutils/config-*` and then `emerge binutils`, does binutils-config get executed automatically ?
Yes it does.
ok ... well if you can track down why it didnt run the first time, please re-open with that info :/
