Re: How to build a 32-bit package in Debian?
Adam Borowski <kilobyte@angband.pl> writes:
> On Wed, Jan 26, 2011 at 12:44:02PM +0100, Goswin von Brederlow wrote:
>> Adam Borowski <kilobyte@angband.pl> writes:
>> > On Mon, Jan 17, 2011 at 11:49:17AM +0800, Paul Wise wrote:
>> >> Add lib32 packages for the deps.
>>
>> Actually you need ia32-libs-dev and also gcc-multilib when you COMPILE a
>> 32bit package. ia32-libs itself is only sufficient for building non-free
>> 32bit packages with prebuild binaries.
>
> Aren't ia32-libs on their way out, together with rest of the bi-arch stuff?
Since sarge, yes. Nothing is as permanent as a quick temporary hack.
>> >> Help fix squeeze RC bugs then start work on multi-arch when the wheezy
>> >> cycle starts.
>> >
>> > There's a wonderful thing called "xapt", aka "multi-arch working today".
>> > Sadly, it can't be integrated into build-depends like real multi-arch will
>> > be, but getting all libraries you need is a matter of typing:
>> >
>> > # xapt -a pdp11 liblossage1 liblossage-dev
>>
>> Please don't use xapt. That tool is so far purely for use in chroots
>> (for pbuilder) and for cross compiling.
>
> Like, building i386 binaries on an amd64?
Yes and no. He wants to build amd64 PACKAGES containing i486-linux-gnu
binaries. With xapt the resulting binary would depend on libc6 instead
of libc6-i386, on libacl1 instead of ia32-libs and so on.
xapt is used when you want to cross build armel packages containing
armel binaries on another arch for later use on armel. That way works.
>> It does not handle any dependencies between 32bit libs and the native
>> packages. E.g. for shared files, conffiles, scripts that need to call
>> other binaries. So using it to execute 32bit binaries will give verry
>> poor results.
>
> It seems to work just fine for me, even for completely foreign architectures
> with no qemu-user installed (in this case you won't be able to run the
> binaries but building works). Not handling dependencies well means just
> that you may have to install them manually.
And dpkg-shlibdebs outputs the dependencies for the foreign arch and not
the local arch so the resulting debs can be installed on the foreign
arch. Not what he wants.
>> The right tool for this would be the old ia32-apt-get
>
> Except, xapt works for all architectures, not just the specific case of i386
> on amd64.
>
>> or the revised apt-ma-emu. Saddly the squeeze freeze hit before
>> apt-ma-emu was ready for upload so it won't be in squeeze.
>
> At a glance, it appears to do the same thing as xapt except that it doesn't
> require manual selection of packages to install and can do upgrades
> automatically. Which are good things, thanks for telling us about this
> tool. It would be nice to have it in experimental.
It might appear so at a glance and you probably looked at an earlier
version. The differences are quite large though in practice. It tries to
emulate what multiarch will do as much as possible and will phase out
its meddling as packages actualy become truely multiarch.
1) Packages for all configured archs are entered in the apt
database. Apt-get, apt-cache, aptitude, synaptic, ... all see the
packages and their own dependency resolvers do all neccessary work to
install the right packages. Dpkg also sees all packages at once so
dependencies between archs are possible.
2) It knows (heuristically from a conffile) which packages should be
Multi-Arch: same (libraries) and which Multi-Arch: foreign
(binaries). Through that it knows that if something depends on gawk it
will install gawk:amd64 (on amd64) while if a i386 package depends on
libfoo it will install install libfoo:i386.
3) The same works for sources too. A Build-Depends: gawk, libfoo-dev
will install gawk:amd64 and libfoo-dev:armel when asked for the source
for armel.
4) apt-ma-emu allows the installation of binaries (xapt calls dpkg-cross
which removes everything that isn't a library). Maintainer scripts are
also run, esspecially important for binary packages. That allows
installing i386 packages on amd64 and run them (as opposed to installing
libs for cross-compiles).
> xapt is there, apt-ma-emu is not (and I didn't know about it). The results
> are awesome -- example build times:
> * native: 115 minutes
> * qemu-system: 133 minutes
> * distcc: 16 minutes
> * xapt: 44 seconds
> And that with a build-dependency chain of over 50 packages, of which I had
> to specify only those directly depended upon.
With apt-ma-emu you have: apt-get build-dep <package>-armel (will become
<package>:arch eventually I guess). No need to specify anything
manually.
> The best we can hope for, though, is apt-ma-emu being already obsolete by
> wheezy.
That would indeed be the best. I doubt all packages (don't forget 3rd
party) will be converted to multiarch by then though. The aim of
apt-ma-emu is to seemlesly blend in with multiarch and only handle the
packages that lack behind. I've only tested this with the 6, at last
count, packages in Debian that are multiarch already but results so far
seem promising.
MfG
Goswin
Reply to: