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

[Simon McVittie]

On 06/07/14 20:38, Lennart Poettering wrote:
> Our understanding so far was more that "multilib" refers to the scheme
> which allows you to run executables of different, but "compatible" archs
> on the same system. In this scheme you would have your each executable
> only of one arch around, but you can relatively freely combine
> executables of different arches into one operating system. An individual
> set of libraries would have to be around for every arch you want to run
> executables of.
> 
> OTOH "multiarch" refers to a much more extensive scheme where the same
> OS image shall be bootable on different (possibly even "incompatible")
> arches, which means you not only require the set of libraries for each
> arch you want to support but also the executables.

No, this is not the case. In multiarch versions of Debian/Ubuntu, you
can have both i386 and x86-64 versions of libc.so.6, but you still only
have one copy of "ls", linked against one or the other. We don't have
/usr/bin/i386-linux-gnu/ls or anything like that.

(We do occasionally have architecture-qualified supporting executables
under /usr/lib, e.g. i386 and x86-64 flavours of gio-querymodules, but
those aren't on $PATH - they're the sort of thing that would go in
/usr/libexec on Red Hat derivatives.)

The big difference between Debian multiarch and older multilib is that
you aren't limited to one 32-bit and one 64-bit ABIs (lib/lib64 or
lib32/lib), but can mix libraries from any number of ABIs, which
simplifies cross-compiling and qemu-system-* emulation considerably. For
instance, on an x86-64 Debian machine that is used for ARM development,
you could usefully have i386, x86-64, armel, armhf and arm64 copies of
libc.so.6, libglib-2.0.so.0 etc.

A new thing here when compared with traditional cross-compiling is that
the various ARM copies of libraries will be in exactly the same place in
the directory hierarchy that they would occupy in a real ARM system, so
build systems that hard-code facts about the build environment and
expect them to be true in the host environment don't get confused.

In principle you could combine x86-64 coreutils with i386 patchutils or
whatever, as long as you have their supporting libraries, but you can
still only have either coreutils:amd64 or coreutils:i386 installed, not
both at the same time, because they both want to install /bin/ls. In
practice, this facility is used for "99% of my system is x86-64 but I
need some i386-only binaries" - usually 32-bit Wine or Flash Player.

> The only problem: systemd is apparently used on more archs that
> Debian has been ported to, and given that we kinda hook into Debian here
> for norming the tuples, we probably have to make up temporary tuples for
> the remaining archs, until Debian picks up those archs too...

Please talk to the dpkg maintainers. They are the "namespace owner"
here, and it seems they are usually willing to include architectures in
dpkg's various tables even when there is no Debian on that architecture
(e.g. lpia and Solaris).

    S