Summary: | sys-libs/binutils-libs-2.27: stabilize (for stable cross-compilers) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick Cripps <nick.cripps> |
Component: | Stabilization | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | joakim.tjernlund, jpizarrocallejas, nick.cripps, slyfox |
Priority: | Low | Keywords: | STABLEREQ |
Version: | unspecified | Flags: | stable-bot:
sanity-check+
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: |
=sys-libs/binutils-libs-2.27
|
Runtime testing required: | --- |
Bug Depends on: | 595288 | ||
Bug Blocks: |
Description
Nick Cripps
2017-03-12 16:18:33 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. 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. *** Bug 612324 has been marked as a duplicate of this bug. *** 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. (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. amd64 stable 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?
(In reply to Joakim Tjernlund from comment #7) an unrelated bug that's already been fixed in newer versions. see bug 563934. (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 (In reply to Joakim Tjernlund from comment #9) if the only thing being listed are internal binutils libs, then yes Stable for HPPA. arm arm64 ppc ppc64 stable. x86 stable sparc stable Stable on alpha. ia64 stable Last arch. Closing. |