From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8872 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Support for multiarch/multilib Date: Tue, 17 Nov 2015 10:36:21 -0500 Message-ID: <20151117153621.GY3818@brightrain.aerifal.cx> References: <20151117150650.GE18372@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1447774628 23167 80.91.229.3 (17 Nov 2015 15:37:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 15:37:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8885-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 16:37:08 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZyiJ9-0002Gd-G4 for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 16:36:35 +0100 Original-Received: (qmail 15630 invoked by uid 550); 17 Nov 2015 15:36:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15610 invoked from network); 17 Nov 2015 15:36:33 -0000 Content-Disposition: inline In-Reply-To: <20151117150650.GE18372@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8872 Archived-At: On Tue, Nov 17, 2015 at 04:06:53PM +0100, Szabolcs Nagy wrote: > * Petr Hosek [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