Re: cross binutils-dev
+++ Marcin Juszkiewicz [2013-01-24 23:57 +0100]:
> I asked Matthias Klose about it nearly year ago:
>
> http://irclogs.linaro.org/2012/03/15/%23linaro.txt
>
> 18:23 < hrw> doko: what would you say for patch which makes binutils
> multiarched? libs/includes in multiarch directories, libbfd and
> libopcodes split to separate packages
> 18:47 < doko> hrw, really no. that would imply that these libraries do
> have a stable interface, which they don't
> 18:49 < hrw> doko: ok, just trying to find a way to install
> binutils-dev:armel on amd64 system
>
> But maybe situation changed.
Doko - please take a look at this thread (starts here:
http://lists.debian.org/debian-embedded/2013/01/msg00011.html )
and say how you would prefer to fix this problem.
I agree there is no stable interface to binutils libs, which is why we
require them to be statically linked, and provide static versions in
binutils-dev. The problem is that we can't install those for the HOST
arch currently (without removing the native binutils).
I don't see why moving them into multiarch locations, in order to
allow co-installability for cross-building is a bad thing, especially
if combined with the private labelling scheme Jonathan suggested using.
Perhaps an alternative is to have only the static libs in
binutils-dev? or split them into a binutils-dev-static package?
I don't see that moving the files has any affect at all on how the
interface is exposed technically - it's exactly as hard/easy to link
statically/dynamically as with the files in the current locations. But
if we use the multiarch paths then we can install the HOST version as
well as the BUILD version, which is necessary far cross-building.
I don't think we can use the ones in the cross-toolchain, (even if
libiberty was added - it's not currently there) because
those libs are built to run on the BUILD arch.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: