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

Lennart Poettering lennart at poettering.net
Sun Jul 6 12:38:10 PDT 2014


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.

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.

Now, Fedora/Redhat only does "multilib" in this sense, and they are
using "lib64" for x86_64 libraries (and "lib" for i386). Debian appears
to go for "multiarch", with different paths. But it's not the name of
the paths that is the distinction between multilib and multiarch, it's
more about whether you have to make a choice about your executables or
not.

(Personally, multilib sounds realistic and useful to me. multiarch sounds
like one of those things where people do things just because they can,
not because they are truly useful...)

> > Well, I am particularly interested in getting this into place so that
> > the debian tuples are used regardless on which distro we built,
> > i.e. even on distros that lack dpkg-architecture.
> 
> I don't think you'll necessarily get that from #ifdefs, although I'd
> like to be proved wrong.

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...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list