On Monday 19 July 2010 21:02:32 Hector Oron wrote: > In 'armhf' case $ gcc -dumpmachine spits the same GCC tuplet (unless > we use GCC vendor tag as an ABI tag) > But `dpkg' do not mach quadruplet names, not yet... ;-)
It does now... :) I had to modify in particular scripts/Dpkg/Arch.pm and scripts/dpkg- architecture.pl to work with quads internally. Vendor is always processed, but is not used unless specified, eg. like in this case with arm-hardfloat- linux.gnueabi. I'll send a patch to dpkg BTS later today. So far it seems to work nicely -I am in the process of bootstrapping armhf, I have ~100 packages essential packages already and the list keeps growing. > We have same GCC tuplet, with different ABI that needs mapping into > Debian naming scheme, how do we workout that (without hacks)? (again, > same questions as above). without multiarch? simple: check arch, armhf instead of armel. > > (BTW... if you want to run both armel and armhf under multiarch... which > > package's libc gets to own ld.so? :P) > > I can't see a use case to run 'armel' binaries on 'armhf' rootfs if > hardware supports it and software is free. From a hardware point of view, if it can run armhf it will certainly be able to run armel. A developer would be able to provide both package versions form the same machine -which is what I do right now, development on armhf happens on just a chroot right now but it could be the other way around, there is nothing in the kernel that requires special treatment. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007192249.39267.mar...@genesi-usa.com
