From: Alexey Neyman <stilor@att.net>
To: Titus von Boxberg <titus@elbe-informatik.de>,
"crossgcc@sourceware.org" <crossgcc@sourceware.org>
Subject: Re: AW: [crosstool-ng/crosstool-ng] 59a784: No need to copy header; libc_start_file does it.
Date: Mon, 16 Jan 2017 16:57:00 -0000 [thread overview]
Message-ID: <b6540c66-ed92-c0c5-4835-55193af95209@att.net> (raw)
In-Reply-To: <379c44656f8049a1939cb87601b1c448@SOLOWJOW.ELBE.local>
[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
>
prev parent reply other threads:[~2017-01-16 16:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-14 5:44 Alexey Neyman
2017-01-14 9:00 ` AW: " Titus von Boxberg
2017-01-16 16:57 ` Alexey Neyman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b6540c66-ed92-c0c5-4835-55193af95209@att.net \
--to=stilor@att.net \
--cc=crossgcc@sourceware.org \
--cc=titus@elbe-informatik.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).