[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: