From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8864 Path: news.gmane.org!not-for-mail From: Petr Hosek Newsgroups: gmane.linux.lib.musl.general Subject: Support for multiarch/multilib Date: Tue, 17 Nov 2015 06:15:20 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114ee32ae2a92c0524b67376 X-Trace: ger.gmane.org 1447740956 31956 80.91.229.3 (17 Nov 2015 06:15:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 06:15:56 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-8877-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 07:15:55 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 1ZyZYS-0006vt-5z for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 07:15:48 +0100 Original-Received: (qmail 3967 invoked by uid 550); 17 Nov 2015 06:15:46 -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 3927 invoked from network); 17 Nov 2015 06:15:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=S6s1Llu3ZxrN4JjCdaqMvuXE+jBLwCgcLYpqEDtafFc=; b=SYtVPA/G9vywD17CZD4Hv6Y0gwqkMCKDdLWmuyVOdWFWOHXeCz5rlRhINtYNbBojae 1bOJ1nE5rW5uPtBY7Fm8y06fR9ur1V//b8hCVw8f8LYk/gzIkQ00GHOR/aLwpJsUYGOl 5BGPreHIeNNGfo2PQZNLRW5XyQ06XWm8UlyDs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=S6s1Llu3ZxrN4JjCdaqMvuXE+jBLwCgcLYpqEDtafFc=; b=O20md5EVAJuzDaiuzyKb6iBVEgNBWJx77wYEL0V2Y1DCANSj0GBrIUn4FhGSgYqNG0 p49iobvWUJrri2EyawE3Wc2QvNBNng82oiYF3IzSSUDKeNsfoJN6jZl+3baboZp82ew6 bef/JNANTKysZqm+0n2bIm8T+5Cu1PurJMttlFSn2vH/riW9DCBqWpNoRK1mTvrsnN3K ztSZrhhzSpQHVXb4WGmERHBlsj8imc4Y7Xy1jEkpZ/49PF7oYlPwF5U5dsPonu5pWbeA 2SMF695r+Nl2fPKO1H5jKsIE2tsm/vUCUZA2qpgi39Dh+lN4XoKkFUad+NdMLu/Tr1Lz pIGQ== X-Gm-Message-State: ALoCoQkaHq2gChR0bjJE0yW18Zg4LRYdX5wEG4dLA9asIlXbM39fhR1fS0A7H2Dd6pjFMsR1o2RS X-Received: by 10.129.136.6 with SMTP id y6mr367772ywf.132.1447740930407; Mon, 16 Nov 2015 22:15:30 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:8864 Archived-At: --001a114ee32ae2a92c0524b67376 Content-Type: text/plain; charset=UTF-8 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. 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? --001a114ee32ae2a92c0524b67376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We're using musl in multiarch/multilib setup (i386/x86= -64) and it works fine, except for header duplication. Given two architectu= res, i386-linux-gnu and x86_64-linux-gnu, I'd like to install the share= d headers into /usr/include, and install bits (what is normally in include/= bits) for each architecture into the respective subfolders /usr/include/i38= 6-linux-gnu/bits and /usr/x86_64-linux-gnu.

I can obviou= sly achieve by copying/moving files after install, but I'd prefer to ha= ve the support for that scenario directly in the Makefile. Would you accept= such patch?

There are two possible ways to implem= ents this I can think of: (1) add a separate targets such as install-arch-h= eaders and install-generic-headers, or (2) define additional Makefile varia= ble 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?
--001a114ee32ae2a92c0524b67376--