Bug 612436 – sys-libs/binutils-libs-2.27: stabilize (for stable cross-compilers)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Nick Cripps 2017-03-12 16:18:33 UTC]

crossdev-S -P -v -t armv7a-hardfloat-linux-gnueabihf failed oin my AMD64 system because when cross-compiling, sys-devel/binutils depends on >= the same version of sys-libs/binutils-libs [1] and, sys-devel/binutils-2.26.1 is stable while there is no sys-libs/binutils-libs-2.26.X in portage (and sys-devel/binutils-2.27.1 and sys-devel/binutils-libs-2.27.1 are not yet stable on AMD64). 

There is an obvious work around: specify an earlier version of binutils using the --b option to crossdev so that there is a stable binutil-libs, which works. 

It would be better to avoid the issue at all by adding and marking as stable sys-devel/binutils and sys-libs/binutils-libs versions together in future when there isn't a good reason not to or, making the toolchain-binutils.eclass more intelligently depend on a sys-libs/binutils-libs version that will work together, rather than just assuming that only equal or later versions work (where clearly sys-libs/binutils-libs-2.25.1-r2 works with sys-devel/binutils-2.26.1 as that is what I have installed for the main toolchain). This would make the -S option to crossdev work and make people's lives easier, therefore making Gentoo as a whole even better. 

[1] lines 107-112 of /usr/portage/eclass/toolchain-binutils.eclass

if is_cross ; then
        # The build assumes the host has libiberty and such when cross-compiling
        # its build tools.  We should probably make binutils itself build a local
        # copy to use, but until then, be lazy.
        DEPEND+=" >=sys-libs/binutils-libs-${PV}"
fi

[Comment 1 Nick Cripps 2017-03-12 16:22:06 UTC]

It doesn't really seem worth the effort to fix this for the current stable versions as the issue will go away after the 2.27.1 versions become stable. Closing with "We'll bear this in mind next time" is a perfectly good fix IMHO.

[Comment 2 Nick Cripps 2017-03-12 16:27:20 UTC]

I should probably note that I have not yest tested the resulting toolchain for the workaround I mentioned, using an earlier version of binutils to match the version of binutils-libs I have installed. I see no reason why it shouldn't work though.

[Comment 3 SpanKY 2017-03-12 21:38:41 UTC]

*** Bug 612324 has been marked as a duplicate of this bug. ***

[Comment 4 SpanKY 2017-03-12 21:51:11 UTC]

normally we would bump them in sync.  the 2.26 release was a bit messed up though, so we ended up not having binutils-libs there.  then we just punted on it and moved to 2.27.

that said, there's no reason we couldn't stabilize binutils-libs-2.27 now.

[Comment 5 Nick Cripps 2017-03-12 22:06:00 UTC]

(In reply to SpanKY from comment #4)
> normally we would bump them in sync.  the 2.26 release was a bit messed up
> though, so we ended up not having binutils-libs there.  then we just punted
> on it and moved to 2.27.
> 
> that said, there's no reason we couldn't stabilize binutils-libs-2.27 now.

Cool. As I said in one of my comments, it isn't hard to work around them not being in sync but, just wanted to make sure it was something people knew about/were aware of so that in normal circumstances, they are. Cheers.

[Comment 6 Agostino Sarubbo 2017-03-13 12:59:40 UTC]

amd64 stable

[Comment 7 Joakim Tjernlund 2017-03-13 19:01:09 UTC]

I got cross binutils:
  cross-powerpc-g2.20-linux-gnu/binutils-2.25.1-r1::tmv3-cross-overlay
that I would like to keep as is ATM.

However as binutils-libs-2.27 got into my system, emerge wants to
rebuild them as it finds ...
existing preserved libs:
>>> package: sys-libs/binutils-libs-2.27
 *  - /usr/lib64/libbfd-2.25.1.so
 *      used by /usr/lib64/binutils/powerpc-g2.20-linux-gnu/2.25.1/libopcodes-2.25.1.so (cross-powerpc-g2.20-linux-gnu/binutils-2.25.1-r1)
 *      used by /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so (sys-devel/binutils-2.25.1-r1)

This repeats over and over again.
I didn't not expect that my cross binutils needs to be in sync with my host.
Is there a way to do what I want?

[Comment 8 SpanKY 2017-03-13 20:00:08 UTC]

(In reply to Joakim Tjernlund from comment #7)

an unrelated bug that's already been fixed in newer versions.  see bug 563934.

[Comment 9 Joakim Tjernlund 2017-03-14 04:05:36 UTC]

(In reply to SpanKY from comment #8)
> (In reply to Joakim Tjernlund from comment #7)
> 
> an unrelated bug that's already been fixed in newer versions.  see bug
> 563934.

Ahh, so it seems.
Scanning that bug and related I could not quite make out if just rm
/usr/lib64/libbfd-2.25.1.so is the fix for now or if that has any hidden
bugs I have yet to see?

If there are some issues I guess i just have to backport
 00_all_0006-opcodes-link-against-libbfd.la-for-rpath-deps.patch
to my older binutils

[Comment 10 SpanKY 2017-03-14 04:58:56 UTC]

(In reply to Joakim Tjernlund from comment #9)

if the only thing being listed are internal binutils libs, then yes

[Comment 11 Jeroen Roovers (RETIRED) 2017-03-15 05:47:31 UTC]

Stable for HPPA.

[Comment 12 Michael Weber (RETIRED) 2017-03-16 09:06:58 UTC]

arm arm64 ppc ppc64 stable.

[Comment 13 Agostino Sarubbo 2017-03-17 10:28:53 UTC]

x86 stable

[Comment 14 Agostino Sarubbo 2017-03-17 10:43:44 UTC]

sparc stable

[Comment 15 Tobias Klausmann (RETIRED) 2017-04-04 19:32:38 UTC]

Stable on alpha.

[Comment 16 Sergei Trofimovich (RETIRED) 2017-06-04 20:05:01 UTC]

ia64 stable

Last arch. Closing.