[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

cross binutils-dev



The kernel build-depends on binutils-dev becuase it needs libiberty.a
from that package to build perf. This tools stuff has been moved out
of the main debian kernel build and Ubuntu are just doing the same
thing (which is good as it simplifies buil-deps greatly), but this
doesn't change the main issue.

libiberty is used to support c++ symbol demangling in perf. It is an
optional feature of the build, but no doubt useful to have and is
enabled by default on linaro ubuntu kernels. 

To cross-build the kernel tools (basically perf) I believe we need
binutils-dev:<HOST_ARCH> because we just need a static library to link
into perf which will run on the HOST_ARCH machine the kernel is built
for. i.e we don't need binutils-dev-<triplet> (which I had originally
assumed would be the case). (someone correct me if I am wrong about
this)

Now binutils-dev is not currenly multiarch, but is just libs and
headers so can easily be made so. However it depends on binutils,
which cannot be an MA:same package as it's full of arch-specific
binaries. (assembler, linker. etc). However it also contins two
libraries 
 /usr/lib/libbfd-2.23.1-system.so
 /usr/lib/libopcodes-2.23.1-system.so
which are also symlink-to by binutils-dev (hence the dependency -
there may be more reasons).

So currently we have a binutils-dev:<HOST> but we can't install it
because the host and build binutils packages would both be needed and
would clash. 

So. what is the correct way to arrange things so that things can
build-dep on the static libs in binutils-dev? There are several of
them - I don't know which packages use the others:
 /usr/lib/libiberty.a
 /usr/lib/libopcodes.a
 /usr/lib/libiberty_pic.a
 /usr/lib/libbfd.a

Is the right thing to do to split binutils and binutils-lib so
binutils-dev is as-is, binutils-lib contains co-installable libraries
(bfd*.so, opcodes*.so, what about all the linker scripts? )and
binutils keeps the binaries and docs.

An alternative would be to leave binutils and split out
binutils-dev-static for cross-use (as I understand there is policy to
only use the static versions of therse libs)

Can someone who understands how this works comment? It's a bit
confusing because we are normally used to thinking about
cross-binutils and its collection of the same stuff built for the
BUILD arch but targetting the HOST arch. So far as I can tell those
are not relevant in this case, and nor can they be used instead. BUt
clearly binutils is not quite your 'normal library, library-dev'
package.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: