From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11209 invoked from network); 13 May 2020 19:34:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 19:34:40 -0000 Received: (qmail 23582 invoked by uid 550); 13 May 2020 19:34:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23561 invoked from network); 13 May 2020 19:34:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K3PmHwIhF+279aEA565h3gCEtPQqBm9Z2f6VuCLkNEQ=; b=Fx8RXg1XoEnp8pVxSDa0EPj/VJDpxbGtJGbpWrRBL/KHg9FFLoQ2Ex1Cim+i0I4a7h x7CjkgrDSZbXt6U06YrgPuegpCJGE/UDOr7k+aM0BdkPrCYpr9iYmbeLu7k9ZJW6620K UFb6nBUPqmNQfVJy72I1KRhkamkUA/rGz5Ghn0swUoX6K+Y6FBAD1xEHg65ZQi8mpfMO O0s+6Gp0r7nAbE5Gmlnn1MkVxQ5qifEZioTx5tMeJ/PpVdILhocISpNI5TDgE73U7+lv PTn/oCGC72xFdLBrTicKceXJa8LncG1QYCRyJQei1P9+h1tLJudxM1I4oZbvsBpSVl6k LIng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K3PmHwIhF+279aEA565h3gCEtPQqBm9Z2f6VuCLkNEQ=; b=LvKfGuITEJuTJ82mOjI023b4wSNuhA+xJA2qR+Y44mcg3anE/SAa9BC4qbV6IwmoQg tooApUFBu+vv8cY4ehZ+7/6yaYwILfDf0mOlOM4lMtC380IKYbIYb5Dw7xZxKtXfmzOL tGgTDFUXGrFVigQuntRuStjnSlZVxBdLS2y6GVkSfOWVy/yygNvkw0dPufjDUg3uUYsU sdL/eOBGrC0nrbZmS1DdEXmwFr33Yre7Ey1BsqnwZfVkBW343+Wo2s1ewVFQo4wRrZq1 51lUBDnFqidEWMWu1/1DX2pi+AD6AHtmZbC9FS8/a4zeVGE75jCG667m+J4837QDCJ/8 qXug== X-Gm-Message-State: AOAM532dHR4fTvzc0UIDjDc/0foH2SiUKZHHhsddQqNmlHeWtSXJDkcE 4fBJgqPmzVFfHNC3Nl6r/Es+8xPb+FNdaq/eyczDDQ== X-Google-Smtp-Source: ABdhPJw1U5uHiaiYrdcAmNSKgkztirj/VEJzfvPpnTU5qzOe9II3zkoY/ST6He+ykyRLMAgoCHoRjlpE6CY55VPi0cU= X-Received: by 2002:a6b:720d:: with SMTP id n13mr814761ioc.20.1589398464416; Wed, 13 May 2020 12:34:24 -0700 (PDT) MIME-Version: 1.0 X-Originating-IP: [73.70.188.119] In-Reply-To: <20200513185551.GZ21576@brightrain.aerifal.cx> References: <20181107064957.1137-1-mforney@mforney.org> <20200323043456.13327-1-mforney@mforney.org> <20200510163555.GU21576@brightrain.aerifal.cx> <20200510215257.GW21576@brightrain.aerifal.cx> <20200513143759.GV21576@brightrain.aerifal.cx> <20200513185551.GZ21576@brightrain.aerifal.cx> From: Michael Forney Date: Wed, 13 May 2020 12:34:23 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Re: [musl-cross-make] [PATCH v2] litecross: Fix system header dir when building native toolchains On 2020-05-13, Rich Felker wrote: > On Wed, May 13, 2020 at 11:48:57AM -0700, Michael Forney wrote: >> It is not relative to /, it is relative to the sysroot, which is >> determined dynamically based on the location of the compiler binary. > > Yes, and what that means is that use of sysroot is just completely > wrong for NATIVE=y. I was under the impression that sysroot was > necessary for making a relocatable toolchain but I've since come to > believe that was a misconception. Is that so? I believe that a sysroot is necessary for making a relocatable toolchain, but it doesn't matter if it is /, /$TARGET, or something else. If you build with --with-sysroot, gcc will look for headers relative to itself, and will not look in /. What doesn't seem to be possible is a "half-relocatable" toolchain, where it searches both in /include relative to the relocated sysroot, and /usr/include on the target system. Perhaps there is some trick or patch that could make this work. > I think it would work to pass --with-native-system-header-dir=/include > for cross and "self-targeting cross" compilers and that this would > allow dropping the usr symlink for these cases, and to make NATIVE=y > stop using sysroot at all (and not use this option). (NATIVE=y should > be more than just $HOST=$TARGET.) But until this NATIVE=y refactoring, shouldn't we fix native toolchains to at least be able to find musl headers? It seems your intention is to search for headers in both /usr/include and $SYSROOT/include, but currently, neither of those is searched, only $SYSROOT/usr/include which does not exist. My patch is intended to just fix this incorrect path, not to change the meaning of NATIVE=y. Such a change should probably involve coordination of Zach van Rijn and Laurent Bercot, both of whom distribute pre-built native toolchains (currently containing a usr -> . symlink). Consumers of those toolchains probably expect a self-contained, relocatable toolchain, since that's what they are currently getting.