Re: Multiarch and ABI support
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
Reply to: