From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87618 invoked by alias); 16 Jan 2017 16:57:36 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 87606 invoked by uid 89); 16 Jan 2017 16:57:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:3438, pretending, H*RU:sk:nm14-vm, HX-HELO:sk:nm14-vm X-HELO: nm14-vm1.access.bullet.mail.bf1.yahoo.com Received: from nm14-vm1.access.bullet.mail.bf1.yahoo.com (HELO nm14-vm1.access.bullet.mail.bf1.yahoo.com) (216.109.115.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jan 2017 16:57:25 +0000 Received: from [66.196.81.163] by nm14.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jan 2017 16:57:24 -0000 Received: from [98.138.226.240] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jan 2017 16:57:23 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 16 Jan 2017 16:57:23 -0000 X-Yahoo-SMTP: 0h0Q7euswBD_g.kcEqbzJWRFfrba801gq1M1 From: Alexey Neyman Subject: Re: AW: [crosstool-ng/crosstool-ng] 59a784: No need to copy header; libc_start_file does it. To: Titus von Boxberg , "crossgcc@sourceware.org" References: <5879bac34a974_4c8d3fa204635138819f4@hookshot-fe2-cp1-prd.iad.github.net.mail> <379c44656f8049a1939cb87601b1c448@SOLOWJOW.ELBE.local> Message-ID: Date: Mon, 16 Jan 2017 16:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <379c44656f8049a1939cb87601b1c448@SOLOWJOW.ELBE.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00019.txt.bz2 [Forgot to CC the list] Titus, First off, the discussion below is a moot point. The issue that prompted this change is that none of the bare metal versions of libc support sysroot: 'none' has no headers/libs to begin with, and avr-libc/newlib do not honor sysroot and hence did not install into a sysroot even before this change. This change just stopped crosstool-ng from pretending it created valid sysroots in these cases. On 01/14/2017 01:00 AM, Titus von Boxberg wrote: > could you elaborate on this one? > Why would a sysroot "imply a file system"? Well, first sysroot stands for "system root". This implies that in a running system, these files are placed at the root of the file system. For example, see that the native gcc reports '/' when doing `gcc --print-sysroot`. Or look at buildroot, that uses toolchain's sysroot as the base for the target's filesystem image. "A sysroot is a folder which contains a minimal filesystem (especially libraries, the C library and header files)" https://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot "sysroots are directory structures that provide the essentials for a system to run" https://www.quora.com/What-is-a-sysroot There seems to be an agreement that sysroot is intended as a *runtime* structure. > Why would "bare metal" not be an OS? It's simply an OS unknown to the toolchain. ... in which case, you will be building the libc, CRT and whatnot for that OS and install them somewhere, then supply the necessary path to the compiler with the --sysroot (again, similar to what buildroot does, for example). Why do you expect the toolchain to know the internal structure of the root file system for the "OS unknown to the toolchain"? In other words, I am not saying it is impossible to use baremetal toolchain to have a sysroot. It is just that you'll have to supply and lay out that sysroot yourself, much like the buildroot does. > Furthermore, I can't see these relationships you claimed between a sysrooted toolchain and an OS or even target file system I hope the above makes it more clear. > A sysroot allows (us) to cleanly separate 3rd party libs from compiler/syslibs installation > (which is very favourable if you want to generate a system installation from sysroot but not gratuitous otherwise). Here, you said it: "a system installation". So we are talking about a filesystem that will be used under some OS, aren't we? Regards, Alexey. > Regards, > Titus > > -----Ursprüngliche Nachricht----- > Von:crossgcc-owner@sourceware.org [mailto:crossgcc-owner@sourceware.org] Im Auftrag von Alexey Neyman > Gesendet: Samstag, 14. Januar 2017 06:45 > An:crossgcc@sourceware.org > Betreff: [crosstool-ng/crosstool-ng] 59a784: No need to copy header; libc_start_file does it. > > > Log Message: > ----------- > Do not use sysroot in bare metal. > > None of the bare metal C library choices (avr-libc, newlib) support installing into sysroot. Nor does it make any sense, since sysroot implies a file system, which in turn implies an OS. > > > Commit: 949cc86ab755ff4fb5971a304ce97c3885fc360e > https://github.com/crosstool-ng/crosstool-ng/commit/949cc86ab755ff4fb5971a304ce97c3885fc360e > Author: Alexey Neyman > Date: 2017-01-13 (Fri, 13 Jan 2017) > > Changed paths: > M config/toolchain.in > M scripts/build/cc/100-gcc.sh > M scripts/build/libc/newlib.sh >