AW: [crosstool-ng/crosstool-ng] 59a784: No need to copy header; libc_start_file does it.

[Alexey Neyman]

[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<stilor@att.net>
>    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
>