Re: Multiarch and ABI support
Hector Oron <hector.oron@gmail.com> writes:
> (CC: debian-dpkg as it is `dpkg' and multiarch related)
> (Reset and rename subject from `Re: cortex /
> arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name
> for an armel variant)' to current)
> (Please follow-up discussion on debian-dpkg@ for multiarch and `dpkg'
> related topics)
>
> Dear Steve,
>
> 2010/7/18 Steve Langasek <vorlon@debian.org>:
>> I'm puzzled why dpkg needs a unique triplet for a port. Â dpkg needs to map
>> port names to triplets, but why does it need to do the inverse? Â And if it
>> doesn't need to map triplet->port, why would the triplet need to be unique?
Another reason is that packages build for one triplet should not be
accidentally installable on another triplet. What is important is that
the ABI is compatible and so far only the debian port name is used to
ensure that, which is based purely on the triplet. So currently the
assumption is that equal (compatible, think i*86-linux-gnu) triplet
means compatible ABI.
> AFAICS `dpkg' relais on -dumpmachine from `gcc'
> scripts/Dpkg/Arch.pm:68: my $gcc_host_gnu_type = `\${CC:-gcc}
> -dumpmachine`;
>
> Then all the magic starts...
> How would `dpkg' can then map GCC tuplets into Debian triplets being
> the same with different Debian architecture names?
>
> $ gcc -dumpmachine
> arm-linux-gnueabi
> $ dpkg --print-architecture
> armel
> which maps to 'armel' on the triplet tables.
> (It seems that those mappings are perl hash maps one-to-one)
>
> 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... ;-)
>
>> There is a need for a distinct port name; I think this is also not a
>> Debian-specific problem, it's a problem common to any distributions that
>> want to do what's described here.
>
> There is no need of distinct port name for 'any' distro. There is need
> of ABI distinction within Debian. How? Adding an ABI control field (as
> I said previously on this conversation)? Codify vendor tag as ABI tag?
> else?
It could be nice to have a full debian i386 port (as we have now) and
partial ports for i586, i686 with just a few relevant packages. All of
them setting ABI: ia32. I know that it is actualy the reverse of what
you suggest but it would work with the same code.
>> Paul commented that:
>>
>>> Anything that relies on the target triplet is going to break as soon as you
>>> move outside a pure Debian system. i.e. any patches relying on a particular
>>> target triplet are inherently Debian specific, and IMO should never be
>>> pushed upstream.
>>
>> But, er, relying on the target triplet for this shouldn't be done in Debian,
>> either!
>
> 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).
>
> This problem can be also seen on MIPS triarch, where Anthony Fok tried
> to bootstrap some MIPS variant during a GSoC [1] (MIPS 3 N32 ABI
> Port), but again they had name clashing.
>
>> FWIW, this discussion ties in with one of the known outstanding issues with
>> multiarch, namely we want to support coinstallation of libraries optimized
>> for multiple /compatible/ instruction sets. Â And we don't want to have to
>> add /lib/i386-linux-gnu, /lib/i486-linux-gnu, /lib/i586-linux-gnu [,...] to
>> the path one by one to accomplish that, especially when we already have
>> hwcaps to do the job for us. Â So perhaps triplets aren't the right level of
>> abstraction to encode in the library paths after all? Â I mean, it's ok to
>> have libraries in /lib/i486-linux-gnu/686/cmov, but we definitely don't want
>> to *change* the library path if and when Debian's base compatibility level
>> moves from i486 to i586 (or from armv4t to armv5t, to keep this on topic ;)
>> and have to deal with path transitions. Â Is there a better identifier we
>> should be using to qualify the library paths, instead of these triplets?
>> I.e., instead of the cpu from the triplet, perhaps there are official names
>> for the ELF architectures that can be used - that can be determined without
>> too much hard-coding all over the place?
The transition should be relatively painless. The triplet comes from
dpkg-architecture and adding multiple triplet paths to
/etc/ld.so.conf.d/ is trivial. So nothing is hardcoded in 99% of
packages. The problem cases are plugins and there the library/app using
the plugin and the plugins themself have to be compiled using the same
triplet. Often a binNMU is enough but sometimes it will require a
versioned Depends.
The ELF architecture is not specific enough. For example both glibc and
uclibc linked binaries are elf_x86-64 but they certainly are not
compatible.
> As I had stated previously my though on another thread [2], there are
> two different cases mixed on `multiarch':
> a) Co-installing libraries (in x86 world, with compatible ABI) which
> main purpose it is to be able to run `non-free' software.
> b) Co-building, which it is the part that affects me the most and can
> be easily solved using sysroot switch on GCC, without any upstream
> changes.
>
> Using sysroot approach you might be able to co-install foreign (other
> arches) libraries into the sysroot for case a) - it even lets the user
> have multiple systems with same ABI and architecture, but with
> different libraries (in the case you want to cross build non Debian
> systems).
Problem there is that cross building still needs some tools to run
during the build. Those need to be available natively. triplet-gcc,
triplet-as, ... are the obvious ones you need anyway but there are a lot
more. Multiarch also gives a way for those tools to be available because
they are listed in Build-Depends[-Indep]. Multiarch adds the knowledge
of which Build-Depends need to be for the cross arch and which natively.
> Current multiarch design, involves upstream changes on GCC (multiarch
> patch has already broken some multilib compilers, see sparc), it also
Actualy pure multiarch in gcc has been complete for some time. What is
being worked on now is combining multiarch with cross compiling and
sysroot to get a more consistent behaviour across the board.
> involves intrusive changes on `dpkg' most criptic code and `apt' graph
> solvers to solve dependencies across arches (which it looks quite hard
> to solve from a mathematical point of view). It also bloats `apt'
Quite trivial from a mathematical point of view. It actually adds
nothing at all to the problem of solving dependencies. It only adds more
nodes to the graph and a few implicit edges. The hard part is changing
the node structure in apt/dpkg to handle multiple packages with the same
name but different arch and adding the implicit edges. Theoretically
this is a breeze, practially that is where the devil is burried.
> cache with several Package files - from embedded point of view, we
> already complain on Packages file size - which you would be amazed how
> big it can grow for several arches. And not to mention, QEmu path
> hacking, and some other issues that shall arise in the way. Is it
> really worth all this pain (nothing compared to bootstrapping a new
> architecture) just for the benefit of running `non-free' software? By
> the time multiarch will be ready, we will already have Just-In-Time
> [3] compilers, where we won't need any architecture, just the source,
> all packages will be arch 'all'.
I and about 70 other users, have used multiarch in its emulated state
through ia32-apt-get for aproaching 2 years now to run non-free software
and WINE. So where is your Just-In-Time compiler? :)
> Please, revisit document HP wrote for Ubuntu [4] and consider sysroot
> as a wider case for 5.1 Chroots point were:
> Advantages:
> â?¢ No development work required. (Great advantage!)
> Disadvantages:
> â?¢ Massive over-use of disk space. (Nowadays, storage disk is cheap,
> and we can implement `dpkg' filters to save space)
> � Requires per-architecture con�guration. (A distributed `dpkg' with
> --root=dir and --force-architecture flags set could do the job)
> â?¢ Lots of work for administrator. (A distributed shell or the right
> bindings in place could also keep up with it)
Always a one shot solution. Every users configuration differs and then
the chroot must be setup differently. Always manual work for the admin
to figure out what is required for the specific system setup so the
chroot works.
Real pain in the ass to get services from outside the chroot to work
right with services from inside the chroot and vice versa. E.g. you do
want to be able to print from acrobat reader, right?
> Plus there is place for multiple binaries as well, that you can easily
> run using QEmu magic.
Much slower to run /bin/bash in qemu than natively and with a chroot you
can't easily mix architectures to run stuff native where possible.
>> (BTW... if you want to run both armel and armhf under multiarch... which
>> package's libc gets to own ld.so? :P)
Both. They must use a different name for their ld.so, like
/lib/ld-linux-x86-64.so.2 and /lib/ld-linux.so.2 on amd64/i386.
Or you need a ld.so that can load both/any library and put that into
libc-bin.
> I can't see a use case to run 'armel' binaries on 'armhf' rootfs if
> hardware supports it and software is free.
I can see a case for compiling package for one on the other and that is
enough to benefit from multiarch.
> Always friendly,
> -- Hector Oron
MfG
Goswin
Reply to: