Multiarch and ABI support
(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?
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?
> 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?
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).
Current multiarch design, involves upstream changes on GCC (multiarch
patch has already broken some multilib compilers, see sparc), it also
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'
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'.
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 configuration. (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)
Plus there is place for multiple binaries as well, that you can easily
run using QEmu magic.
> (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.
Always friendly,
-- Hector Oron
[1] http://wiki.debian.org/SummerOfCode2009#MapofDebianprojects
[2] https://bugs.launchpad.net/gcc-linaro/+bug/602743/comments/4
[3] http://en.wikipedia.org/wiki/Just-in-time_compilation
[4] http://multiarch.alioth.debian.org/multiarch-hp-report.pdf
(BTW... Is Linaro GCC yet another EGCS?)
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
Reply to: