binutils: Split out libiberty-dev to multiarch paths

[Wookey]

The kernel build-depends on binutils-dev for builds, (because libiberty is used for perf in the linux-tools package). This prevents automated kernel cross-building because binutils-dev is not Multi-Arch: same, and cannot be easily made so due to its dependency on binutils. So apt-get --only-source build-dep -a linux fails

The maintainer's suggested fix is to split out the libiberty static library into an M-A: same package, which the kernel can then build-depend on.

The attached patch implements this.

[Matthias Klose (doko)]

wrong. this should be a separate *source* package. or better don't use libiberty but gnulib instead.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "binutils_2.23.1-0ubuntu6-libiberty-dev.patch" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Wookey (wookey)]

But it isn't a separate source - it's all built together from the binutils source. What's the point of having another copy of binutils upstream source to make libiberty-dev out of?

And I/we have no control over which libraries upstreams use. There are 40 source packages that build-dep on binutils-dev. I don't know if all of those are using libiberty or something else in binutils-dev (about 10 are kernels so those all will be). We can start telling people to use gnulib if that is equivalent, but in the meantime people need to cross-build kernels, so some solution is needed, and it is likely to take a long time to get them all to change unless it's something mechanical we can fix in the distro.

[Matthias Klose (doko)]

so, this issue got re-assigned to binutils, now closing it as won't fix.

there is more than one package shipping libiberty sources, and each of these packages does use these privately.

so if you find the libiberty sources in another source package than binutils or gcc-4.x, then please build these packages from this source. It's a misunderstanding that libiberty has a public or stable interface. Building libiberty-dev from one of these packages would just acknowledge this.