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

[Tollef Fog Heen]

]] Lennart Poettering 

> On Fri, 04.07.14 20:30, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:
> 
> > 
> > On 03/07/14 14:27, Lennart Poettering wrote:
> > > BTW, to clarify what this is about I will now rename the tupel macro
> > > from ARCH_TUPLE to LIB_ARCH_TUPLE or so, since this is about locations
> > > for shared libraries, nothing else.
> > 
> > Please consider calling it something with MULTIARCH in if you're using
> > Debian multiarch tuples, maybe LIB_MULTIARCH or LIB_MULTIARCH_TUPLE -
> > that's the consistent Debian/Ubuntu naming for these tuples (e.g.
> > DEB_{HOST,BUILD}_MULTIARCH in dpkg-architecture).
> > 
> > In particular, please avoid calling it "multilib", which seems to be
> > fairly consistently used to refer to the lib/lib64/lib32 style of
> > naming.
> 
> 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.

multiarch vs multilib has nothing to do with booting the system.  When
we started using the term, we did not want to talk about multilib, since
that was already in use for gcc's -m32 and -m64 support.  Its scope has
later expanded, it seems.

> Or with other words: on multilib your /usr/bin/ls binary can be i386 or
> x86_64 but you have to chose one at a time, and can only installl one at
> the same time. On multiarch you could have both binaries around, and
> when you boot on an actual 32bit processor you get one, while if you
> boot on a 64bit processor you would get the other.

This is an incompatible use of the term multiarch from what it means in
Debian and my master's thesis from 2005 (which the multiarch design in
Debian is largely based on).

Multiarch is a way for binaries for multiple architectures to co-exist
within a single file system hierarchy, principally by avoiding
overlapping paths.  There is no requirement for the architectures to be
compatible in any way as long as the kernel is able to run binaries for
the given architectures (so i386/amd64 is fine, but so is amd64/powerpc
through the use of qemu and binfmt-misc or amd64-linux+amd64-win64
through wine).

> Zbigniew tracked done the necessary macros to check for to distuingish
> the various ARM ABIs. This means things are looking pretty good on this
> front. 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...

dpkg has arch tuples for more architectures than people use Debian on
too, so they'll likely be happy to incorporate the names of whatever
architectures you find.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are