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 6628 invoked from network); 13 May 2020 18:49:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 18:49:14 -0000 Received: (qmail 29771 invoked by uid 550); 13 May 2020 18:49:11 -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 29744 invoked from network); 13 May 2020 18:49:10 -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=a+73nWz5JioVRK2O3MNQap08+QvzmOtb0X6hXh21SiM=; b=UC/CEkVBuNF+v38abM1zG2lZKW+3+73plPlhAk2WnQaaj5TOQSo66F/2cNmlUPvKA4 WIcawtIixoqQBOe7LGsFkzEDK8gtk0zLbOUgdev5aH3GqJ4SHiKeftuY4pLN6BXFLlAU oMWeVVia2IsaepBHCJzXN00XimMNEiGINBlMM4kgsWajntHkM2UMJd4uji5mbN5yqRPS 2D0F3sc3qgm5rkvUsq+CFxG14eLEuV7ETIxWzVcGHkqCLyqtKRd6XFrBSyePzG/I5oWg pVOHSEtrjM684GaDjfkQ0Gw7BXJv6oFtF7sNYVHhM9DaiPDJXM5WfrCyI9u2Rynp5Z7S 8i3Q== 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=a+73nWz5JioVRK2O3MNQap08+QvzmOtb0X6hXh21SiM=; b=YfVEQvysr4y8xTy4TBix0ioYlHEnIWVXIzRRB6Z13iJiN5abXBiwwJ4O65R2yuTien 7ne/sXTJgfeH33NEeUZxAF22gizeEwBLT8S3RJNnB6MCmUmbgqlXWB1hlLOn4aH4gHBl rSjSRVLKsxV2KiB00hQOZupZRaC69dV7//WiKxklzRLiwt1hdmLtAeExO4a97ymVcnjF vA0d+GKzxFdtcl9XiI6KVF3jOTRJ05hCKFHbeivxFbrYOg0UOv1r+8cZCpR75LOgJWf8 R0yKr/kZXY56zyp9viuBOpCjxHZZKAzirYGCa2GilDA3C4YqwV/LYXIyiRl1F/R3yevc hhlA== X-Gm-Message-State: AGi0PuYUlkJTOJVj4sbEJDqsvdIBxrddAkZrYzBt56yrZOMYp4L4JfpQ MtHmArsnH5RcGqpYT6YTqV231eh5WqrL/wX1J/tH8f+0 X-Google-Smtp-Source: APiQypLoRA8rBfyklGzZc0ly5Lc+gdnBwANjLs+ZYyYF2qOpiH7ksa2jyN3i2WXA3sIsR40iOQVYUUQcLA/VBvmP+VQ= X-Received: by 2002:a02:7a12:: with SMTP id a18mr882312jac.49.1589395738347; Wed, 13 May 2020 11:48:58 -0700 (PDT) MIME-Version: 1.0 X-Originating-IP: [73.70.188.119] In-Reply-To: <20200513143759.GV21576@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> From: Michael Forney Date: Wed, 13 May 2020 11:48:57 -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: > What the sysroot dir is for a cross toolchain is an implementation > detail of the cross compiler toolchain. It's not part of any larger > filesystem on the target. All the paths I'm talking about are relative to the relocatable sysroot. Whenever I speak of $SYSROOT, I mean the dynamically determined sysroot path relative to the compiler binary. The larger filesystem on the target is irrelevant here. > For a native compiler, the include path is supposed to be the normal > native one. For a self-targeting cross compiler (one possible > interpretation of native that wasn't my intent) it's not. These should > probably be distinct supported cases. Okay, but this is not how it works currently, and does not seem to be how people expect it to work. Both native and cross compilers search for headers in $SYSROOT/usr/include, where $SYSROOT is determined relative to the compiler binary. /usr/include on the actual system root is not considered. >> Currently, gcc is searching for headers in $SYSROOT/usr/include, as it >> does by default, but we can configure gcc to instead search >> $SYSROOT/include (where the headers actually are) by using >> --with-native-system-header-dir=/include. > > "Where they actually are" is a mistake. There is no intent to put > /include on the target system at all. It was probably a mistake to > even make this sysrooted the way it is but I don't know the right way > to do it. Maybe it's just turning off sysroot. Toolchain headers > should be relative to the toolchain install location so that you can > install it wherever you want (/opt, /usr/local, ~, whatever) while > native system headers should be searched in the standard locations. I think you are misunderstanding what the "native system header dir" is. Here's the gcc documentation: --with-native-system-header-dir=dirname Specifies that dirname is the directory that contains native system header files, rather than /usr/include. This option is most useful if you are creating a compiler that should be isolated from the system as much as possible. It is most commonly used with the --with-sysroot option and will cause GCC to search dirname inside the system root specified by that option. It is not relative to /, it is relative to the sysroot, which is determined dynamically based on the location of the compiler binary. For a cross toolchain we currently have: gcc binary: /some/path/bin/gcc sysroot: ../x86_64-linux-musl native system header dir: ../x86_64-linux-musl/usr/include musl header install directory: ../x86_64-linux-musl/include For a native toolchain we currently have: gcc binary: /some/path/bin/gcc sysroot: ../ native system header dir: ../usr/include musl header install directory: ../include So --with-native-system-header-dir=/include will indeed search where the headers actually are, wherever the toolchain might have been relocated.