[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 17 Nov 2015 10:36:21 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Support for multiarch/multilib
On Tue, Nov 17, 2015 at 04:06:53PM +0100, Szabolcs Nagy wrote:
> * Petr Hosek <phosek@...omium.org> [2015-11-17 06:15:20 +0000]:
> > We're using musl in multiarch/multilib setup (i386/x86-64) and it works
> > fine, except for header duplication. Given two architectures,
> > i386-linux-gnu and x86_64-linux-gnu, I'd like to install the shared headers
> > into /usr/include, and install bits (what is normally in include/bits) for
> > each architecture into the respective subfolders
> > /usr/include/i386-linux-gnu/bits and /usr/x86_64-linux-gnu.
> >
>
> multiarch should make it possible to support multiple abis
> on the same host.. but currently that's not the case, there
> are headers shared across abis.
>
> $ARCH-linux-gnu is certainly not the right name for musl as
> it conflicts with glibc.
And it's just semantically wrong since there's no gnu involved.
In any case, I would really rather keep the assumption that only the
bits directory is arch-specific out of musl and its build system.
Several times I have toyed with the idea of merging arch-specific
definitions into the main headers at musl build time. Right now, the
only criterion for whether something appears in the top-level header
or bits is whether it actually varies by arch, which is very arbitrary
from a user perspective.
Even without such a change, things could also get really messy if you
have different versions of musl installed for different archs. The
interface between the top-level headers and bits is not a public API
boundary, and can and does change between musl versions.
Really the top-level headers are so small I can't see a practical need
for reusing them across archs on a multi-arch system. Why not just put
all of the libc headers under /usr/include/$arch-linux-musl, with bits
then under /usr/include/$arch-linux-musl/bits, and set the compiler
multiarch include paths accordingly?
Of course trying to share /usr/include for anything, even third party
library headers, also assumes that none of them are installing
arch-specific (generated or otherwise) headers to $includedir. This
might or might not be a valid assumption. I think the old model of
separating everything into /usr/$tuple/{lib,include,...} made a lot
more sense than trying to split up /usr/include like Debian does.
> > I can obviously achieve by copying/moving files after install, but I'd
> > prefer to have the support for that scenario directly in the Makefile.
> > Would you accept such patch?
> >
> > There are two possible ways to implements this I can think of: (1) add a
> > separate targets such as install-arch-headers and install-generic-headers,
> > or (2) define additional Makefile variable such as includebits which would
> > be set to $(includedir)/bits by default but could be overridden when
> > invoking make. Do you have strong preference for either of these solutions?
>
> i personally prefer something with make variables so
> make install does the right thing if i set my vars
> properly. (i assume you need the same for /usr/lib.)
>
> but i'm not sure if trying to support a particular
> flavour of multi* is a good idea at this point.
As long as there are various multiarch flavors and they're not cleanly
integrated with upstream compilers, I think it makes a lot more sense
to do the multiarch install as an external, distro-specific script
operating on the staged output of the libc 'make install' rather than
trying to support one or more of them directly in the makefile install
targets. In the long term if more consensus is reached on the matter
it may make sense to revisit this. Does that sound reasonable?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
