Re: Packaging a library that requires cross-compiled code
David Anderson writes ("Packaging a library that requires cross-compiled code"):
> 2) Package an arm7 cross-compiling gcc with just the right set of
> options, integrate that with the packaging tools, and then package
> with a Build-Depends on the cross-compiler.
>
> Pro: feels like the Right Way, in a perfect world. Cons: opens the
> floodgates of packaging cross-compilers, likely requires
> additions/modifications to packaging tools, and takes way more time
> than I'm personally ready to put into packaging my code.
This is the right answer I think. Several other embedded systems
already have cross-compilers in Debian, so this isn't opening any
floodgates or getting into anything too unusual. I can see why it
would be hard work for you to learn about packaging cross-compilers.
> 3) Somehow make the packaging tools properly cross-compile the .bin
> without having a cross-compiler package around. This was briefly
> suggested on #debian-mentors, but I have no idea how this would be
> implemented.
It's not clear what you mean here. 136 bytes seems very little. Is
it written in an assembly language or in C ?
> Pros: less time involved than 2), would make the package
> self-contained. Cons: building a cross-compiler in the packaging
> process just to build a 136 byte binary blob feels like killing a flea
> with a bazooka, and makes building the package much, much longer than
> it should be, given the amount of code and logic it actually carries.
Yes, but I think that sounds like an acceptable alternative.
> 1) Ship a built copy of the code in the package's .diff.gz, and DTRT
> at package creation time to move the .bin from debian/ to the right
> place in the staging tree. The source code for the .bin is in
> .orig.tar.gz, under a free license. Anyone is free to modify or
> rebuild the .bin, provided they obtain an arm7 cross-compiler by
> non-debian means (instructions provided). People who just want to
> rebuild the package can do so, without caring that there is
> cross-compiled code involved.
>
> Pro: dead simple, the packaging problem goes away. Con: means shipping
> a binary blob in the source distribution, which appears to be frowned
> upon, regardless of whether the source is also freely available in the
> source distribution.
This is (unfortunately for you) not acceptable for Debian proper.
Everything in Debian must be buildable from source using tools in
Debian.
> 4) Give up and stay away from the Debian main repositories, just put
> the package up on a private package repository.
>
> Pro: trivial solution. Cons: I'd like to do things right rather than
> cobbling something together.
You could put the package in contrib. I think contrib would be
a possibility for this. But it's far from ideal - think of the poor
users who want to change the 136-byte loader program.
Ian.
Reply to: