Adam Borowski <kilob...@angband.pl> writes: > On Wed, Jan 26, 2011 at 12:44:02PM +0100, Goswin von Brederlow wrote: >> Adam Borowski <kilob...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp33mubq.fsf@frosties.localnet