[systemd-devel] [PATCH] arch: add crisv32

[Simon McVittie]

On 03/07/14 12:09, Lennart Poettering wrote:
>           32bit ARM (yay, at least 4 ABIs to choose from, well done!)

The current status quo in Debian and its derivatives seems to be "when
introducing a new ARM flavour, the ARM and toolchain people argue about
its canonical name for a while". There are more possible permutations
than those four (arm, armel, armhf, armeb), they're just the ones where
someone has made a serious attempt to build Debian.

I don't think you can necessarily infer the Debian multiarch tuple of
containers/chroots (if that's what you're trying to do) from the
compiler architecture, or even the Debian multiarch tuple, of systemd.
Debian armel systems can still run Debian arm (old ABI) executables -
you have to use a chroot because the userland ABIs are different, but
the kernel can go either way. Similarly, I think armhf systems can run
armel executables, and possibly even arm OABI too.

If all you need is the multiarch tuple of the ABI with which systemd
itself was compiled, for distributions that use Debian-style multiarch
tuples, you might be better off providing a configure option
"--with-multiarch-tuple" or something that overrides/ignores the
#ifdef-based logic - then Debian could compile systemd with

    --with-multiarch-tuple=$(dpkg-architecture -qDEB_HOST_MULTIARCH)

and it would be completely unambiguous.

> Note that different Linux distributions tend to use different
> triplets. For example, on FEdora:
>
>    $ gcc -dumpmachine
>    x86_64-redhat-linux
>
> I am mostly interested in the Debian-version of the tuples, as they
> don't bake any company or distro name into the string.

Debian multiarch tuples are intentionally not necessarily the same as
Debian compilers' "gcc -dumpmachine" output: they're a normalized form,
using the oldest or most generic member of a family of interoperable ABIs.

The main practical example is that Debian's 32-bit x86 gcc thinks it's
i486-linux-gnu, and Ubuntu's equivalent thinks it's i686-linux-gnu; but
because different libraries compiled for i386, i486 and i686 can safely
exist in the same process space, and i386 is the oldest/most generic, we
use i386-linux-gnu for the multiarch tuple.

Similarly, Debian on ARM is always arm-linux-gnu plus some ABI suffix,
never armv4tel-linux-gnu or armv6iddqd-linux-gnu or some similar
CPU-specific thing (although so is our compilers' gcc -dumpmachine, as
it happens).

It's unfortunate that we had to use arm-linux-gnu, arm-linux-gnueabi,
arm-linux-gnueabihf, ... for the various incompatible flavours of ARM,
but that seems to be how ARM (and in particular its floating-point)
works. MIPS has had similar issues with "n32", "o32" ABI variants.

> Currently the following archs are broken in this regard:
...
> ppc64le

dpkg-architecture knows about various architectures that don't exist as
full ports in Debian, including ppc64el (appears to be
powerpc64le-linux-gnu) and mips64 (appears to be mips64-linux-gnuabi64),
although not tilegx or cris. It would probably be worth talking to the
dpkg maintainers, who manage the multiarch tuple namespace.

    S