Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
To add to this, my understanding of why you need the symlink at all has to do with overcoming some hard assumptions in the build systems of certain packages. A lot of system programs wind up hardcoding paths into their executables and scripts so that they are using their expected versions and can't be circumvented by trivial things like PATH variables. It is kind of important that the initial build can actually use the path the runtime will end up seeing, especially since LFS starts using the tools as they are incorperated during the toolchain build itself. The location of /tools is arbitrary in the context of how it works. It's just nice to type and is appropriately named. Jonathan On Tue, May 19, 2020 at 4:03 PM Bruce Dubbs via lfs-dev < lfs-dev@lists.linuxfromscratch.org> wrote: > On 5/19/20 2:25 PM, Akira Urushibata via lfs-dev wrote: > > Is there any problem with making a new directory at the filesystem > > base level? > > > > In theory there could be a distribution which already has a /tool > > directory. But I have never heard of that. > > > > What alternatives are there to /tool ? If /tool is so abhored, why > > not try /usr/local instead ? What happens when you do that? > > The /usr/local directory must be empty for this to work and you > > shouldn't do anything other than build LFS on this system. But if > > you dislike /tool , it should be worth a try. > > We use /tools -> /mnt/lfs/tools as a location for creating the temporary > tools used to build the system in Chapter 6. In that way files like > /tools/bin/make can be found via the identical path from the host and > from within chroot. When rebooting the completed system, the host's > /mnt/lfs/tools becomes a directory, /tools, not a symlink, but is not used. > > The FHS says that "*distributions* should not create new directories in > the root hierarchy without extremely careful consideration of the > consequences including for application portability." > > LFS is not designed to be a distribution although many treat it that > way. Your distro, your rules. > > Additionally, there is nothing preventing an LFS user from deleting or > moving /tools from the host any time after Chapter 6. /tools and > /mnt/lfs/tools are really only temporary constructs. > > I'll note that I have several non-FHS anointed entries in /: /build, > /jhalfs, lost+found, and /sources. Actually lost+found is almost always > found for all distributions but is not mentioned in the FHS. > >-- Bruce > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On 5/19/20 2:25 PM, Akira Urushibata via lfs-dev wrote: Is there any problem with making a new directory at the filesystem base level? In theory there could be a distribution which already has a /tool directory. But I have never heard of that. What alternatives are there to /tool ? If /tool is so abhored, why not try /usr/local instead ? What happens when you do that? The /usr/local directory must be empty for this to work and you shouldn't do anything other than build LFS on this system. But if you dislike /tool , it should be worth a try. We use /tools -> /mnt/lfs/tools as a location for creating the temporary tools used to build the system in Chapter 6. In that way files like /tools/bin/make can be found via the identical path from the host and from within chroot. When rebooting the completed system, the host's /mnt/lfs/tools becomes a directory, /tools, not a symlink, but is not used. The FHS says that "*distributions* should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability." LFS is not designed to be a distribution although many treat it that way. Your distro, your rules. Additionally, there is nothing preventing an LFS user from deleting or moving /tools from the host any time after Chapter 6. /tools and /mnt/lfs/tools are really only temporary constructs. I'll note that I have several non-FHS anointed entries in /: /build, /jhalfs, lost+found, and /sources. Actually lost+found is almost always found for all distributions but is not mentioned in the FHS. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On Tue, May 19, 2020 at 10:33 PM Akira Urushibata via lfs-dev wrote: > > Is there any problem with making a new directory at the filesystem > base level? > > In theory there could be a distribution which already has a /tool > directory. But I have never heard of that. > > What alternatives are there to /tool ? If /tool is so abhored, why > not try /usr/local instead ? What happens when you do that? > The /usr/local directory must be empty for this to work and you > shouldn't do anything other than build LFS on this system. But if > you dislike /tool , it should be worth a try. > > > > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page No not at all, I'm actually a fan of the `/tools` symlink on the host file system (as it has become sort of a convention, and it's known by many users), but I was just seeing if providing it can be optional. I understand that `/$dir` and `/home/lfs/$dir` have to exist to get the chroot linker's paths correctly sorted out, but after looking at some other options, I'm lead into thinking that `/tools` might be the best place for this symlink to go to. Some alternatives are: 1- No host symlink, will have to be `/home/lfs/home/lfs/tools` symlink to `/home/lfs/tools` in order to work inside and outside of chroot. Pros: No host symlink Cons: Inconvenient path `/home/lfs/home/lfs/tools 2- `/opt/lfs/tools` host symlink to `/home/lfs/opt/lfs/tools` (will also have to provide /home/lfs/tools -> `/home/lfs/opt/lfs/toolchain` or vice versa because it's what the user expects). Pros: Host symlink conforms to FHS v3.0 Cons: Still a host symlink + inconvenient name `/home/lfs/opt/lfs/tools` (might also be overridden when an opt dir is actually needed inside chroot?) + an additional symlink /home/lfs/tools for where the user expects to find the toolchain. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Why is the /toolchain symlink on the host system even needed?
Is there any problem with making a new directory at the filesystem base level? In theory there could be a distribution which already has a /tool directory. But I have never heard of that. What alternatives are there to /tool ? If /tool is so abhored, why not try /usr/local instead ? What happens when you do that? The /usr/local directory must be empty for this to work and you shouldn't do anything other than build LFS on this system. But if you dislike /tool , it should be worth a try. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On Sat, May 16, 2020 at 6:46 AM Xi Ruoyao via lfs-dev wrote: > > On 2020-05-16 06:03 +0300, Firas Khalil Khana via lfs-dev wrote: > > On Sat, May 16, 2020 at 5:48 AM Xi Ruoyao via lfs-dev > > wrote: > > > On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote: > > > > On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev > > > > wrote: > > > > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > > > > > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > > > > > > wrote: > > > > > > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > > > > > > wrote: > > > > > > > > Hey there, > > > > > > > > > > > > > > > > I'd like to inquire about the actual need for the /toolchain > > > > > > > > symlink > > > > > > > > on the host system. > > > > > > > > > > > > > > > > Apparently, failure to create this link causes > > > > > > > > configure/build/linking > > > > > > > > problems starting from Chapter's 5 libstdc++ with errors in the > > > > > > > > form > > > > > > > > of failure to perform sanity checks (mostly because cpp's (gcc > > > > > > > > -E) > > > > > > > > include paths are wrong), ld not finding crt1.o, crti.o, and so > > > > > > > > on... > > > > > > > > > > > > > > > > I'm not really sure why this link is required though. I > > > > > > > > understand > > > > > > > > that it's currently a must to build LFS (apparently not much > > > > > > > > explanation is provided to how GCC/Binutils > > > > > > > > searching/configuring > > > > > > > > works with regards to directory layout,so we need to cover for > > > > > > > > $LFS/tools and /tools with the latter being silently used in > > > > > > > > some > > > > > > > > places to make the toolchain build; by silently I mean > > > > > > > > automatically > > > > > > > > appended to $LFS without knowing when/where so it won't error > > > > > > > > out), > > > > > > > > but wouldn't specifying correct flags when configuring GCC, > > > > > > > > binutils > > > > > > > > and Glibc remove the need for such symlink? > > > > > > > > > > No, unless we use some DESTDIR installation. It's Pierre's cross > > > > > Chapter 5 > > > > > experiment: > > > > > > > > > > http://www.linuxfromscratch.org/~pierre/lfs-modified/ > > > > > > > > > > > > > I've checked piere's modifications, and they're most welcome, but I'm > > > > only talking about removing the `/tools` symlink without touching > > > > anything else. > > > > > > > > I don't think GCC needs its source modifications be changed (meaning > > > > that we'll still use the regular `/tools/lib`), and I think that's > > > > made possible because sysroot is actually appended before ld's search > > > > path (one thing that might require minor modification is that when ld > > > > inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying > > > > `t-linux64` to use `../lib` instead of `../lib64`) path relative to > > > > where it is, it won't get the right `lib` folder as it gets to > > > > `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the > > > > configuration passed to the toolchain components. > > > > > > It's not about library search path. It's about GCC internal executable > > > path. > > > When you configure GCC with --prefix=/mnt/lfs/tools, the path > > > "/mnt/lfs/tools/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/" gets hardcoded > > > into > > > executables gcc, g++, etc. When this GCC build is used, it searches > > > internal > > > executables cc1, cc1plus, etc. in this path. So if we use -- > > > prefix=/mnt/lfs/tools for GCC pass 2, it will be unusable at all in chroot > > > (gcc > > > will say something like 'cc1 not found'). And there is a GCC library path > > > "/mnt/lfs/tools/lib/gcc/x86_64-linux-gnu/10.1.0" contains libgcc libraries > > > and > > > headers. It's also hardcoded. > > > > > > > ^ This needs to be added to the book, along with explanations for the > > rest of the stuff LFS does to get a cross/native toolchain to work. > > Also if that's the case, why not rely on empty prefixes, and resolve > > to `DESTDIR`s instead? > > If we use --prefix=/usr and DESTDIR=/mnt/lfs for GCC pass 2, it would be only > usable in chroot, and unusable outside chroot. So the remaining packages in > Chapter 5 need to be built either by GCC pass 1, or inside the chroot > environment. That's exactly Pierre's modification. > > /* snip */ > > > > > https://stackoverflow.com/questions/59705962/ld-fails-to-find-libc-when-compiling-first-pass-of-cross-gcc > > > > > > The mistake is using gcc-9.x instruction for gcc-8.x. gcc-8.x needs " > > > --disable- > > > libmpx". > > > > > > > I was just referring to a similar problem, `libmpx` and `libmudflap` > > are long gone in GCC... > > > > > Please do not arbitrarily change package version. And, please investiate > > > the > > > error message to understand what's happening when you hit a problem, > > > instead > > > of > > > guessing and blaming "/tools". > > > > > > > I'm not
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On Sat, May 16, 2020 at 5:48 AM Xi Ruoyao via lfs-dev wrote: > > On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote: > > On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev > > wrote: > > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > > > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > > > > wrote: > > > > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > > > > wrote: > > > > > > Hey there, > > > > > > > > > > > > I'd like to inquire about the actual need for the /toolchain symlink > > > > > > on the host system. > > > > > > > > > > > > Apparently, failure to create this link causes > > > > > > configure/build/linking > > > > > > problems starting from Chapter's 5 libstdc++ with errors in the form > > > > > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > > > > > include paths are wrong), ld not finding crt1.o, crti.o, and so > > > > > > on... > > > > > > > > > > > > I'm not really sure why this link is required though. I understand > > > > > > that it's currently a must to build LFS (apparently not much > > > > > > explanation is provided to how GCC/Binutils searching/configuring > > > > > > works with regards to directory layout,so we need to cover for > > > > > > $LFS/tools and /tools with the latter being silently used in some > > > > > > places to make the toolchain build; by silently I mean automatically > > > > > > appended to $LFS without knowing when/where so it won't error out), > > > > > > but wouldn't specifying correct flags when configuring GCC, binutils > > > > > > and Glibc remove the need for such symlink? > > > > > > No, unless we use some DESTDIR installation. It's Pierre's cross > > > Chapter 5 > > > experiment: > > > > > > http://www.linuxfromscratch.org/~pierre/lfs-modified/ > > > > > > > I've checked piere's modifications, and they're most welcome, but I'm > > only talking about removing the `/tools` symlink without touching > > anything else. > > > > I don't think GCC needs its source modifications be changed (meaning > > that we'll still use the regular `/tools/lib`), and I think that's > > made possible because sysroot is actually appended before ld's search > > path (one thing that might require minor modification is that when ld > > inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying > > `t-linux64` to use `../lib` instead of `../lib64`) path relative to > > where it is, it won't get the right `lib` folder as it gets to > > `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the > > configuration passed to the toolchain components. > > It's not about library search path. It's about GCC internal executable path. > When you configure GCC with --prefix=/mnt/lfs/tools, the path > "/mnt/lfs/tools/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/" gets hardcoded into > executables gcc, g++, etc. When this GCC build is used, it searches internal > executables cc1, cc1plus, etc. in this path. So if we use -- > prefix=/mnt/lfs/tools for GCC pass 2, it will be unusable at all in chroot > (gcc > will say something like 'cc1 not found'). And there is a GCC library path > "/mnt/lfs/tools/lib/gcc/x86_64-linux-gnu/10.1.0" contains libgcc libraries and > headers. It's also hardcoded. > ^ This needs to be added to the book, along with explanations for the rest of the stuff LFS does to get a cross/native toolchain to work. Also if that's the case, why not rely on empty prefixes, and resolve to `DESTDIR`s instead? > One way to solve this is to add CC="gcc -B /tools/libexec/gcc/x86_64-linux- > gnu/10.1.0 -L /tools/lib/gcc/x86_64-linux-gnu/10.1.0 -I /tools/lib/gcc/x86_64- > linux-gnu/10.1.0/include" in early Chapter 6 packages. I believe such a long > $CC is stupid. > > Another way, already said by Pierre, is "ln -sv /tools /mnt/lfs" in chroot > environment. > > > > > > > These errors can be evaded by closely examining > > > > > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > > > > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed > > > > > > command > > > > > > to "../../lib" based on where ld is searching), along with > > > > > > `--with-lib-path` in binutils pass 1. > > > > > > > > > > > > I'm curious to hear your thoughts on the matter. > > > > > > > > > > > > Thanks for your time and effort. > > > > > > > > > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > > > > > we have /tools. But then, when going to chapter 6, some search paths > > > > > would contain $LFS/tools, that we do not have in chroot. That's the > > > > > reason to have the link and use it in chapter 5. > > > > > > > > > > > > > > > Note, we could maybe create /mnt/lfs in chroot, and have: > > > > > /mnt/lfs/tools->/tools in chroot. > > > > > Never tried. > > > > > > > > > > Pierre > > > > > > > > > > > > > > > -- > > > > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > > > > FAQ: http://www.linuxfromscratch.org/faq/ >
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On 2020-05-16 04:37 +0300, Firas Khalil Khana via lfs-dev wrote: > On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev > wrote: > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > > > wrote: > > > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > > > wrote: > > > > > Hey there, > > > > > > > > > > I'd like to inquire about the actual need for the /toolchain symlink > > > > > on the host system. > > > > > > > > > > Apparently, failure to create this link causes > > > > > configure/build/linking > > > > > problems starting from Chapter's 5 libstdc++ with errors in the form > > > > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > > > > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > > > > > > > > > I'm not really sure why this link is required though. I understand > > > > > that it's currently a must to build LFS (apparently not much > > > > > explanation is provided to how GCC/Binutils searching/configuring > > > > > works with regards to directory layout,so we need to cover for > > > > > $LFS/tools and /tools with the latter being silently used in some > > > > > places to make the toolchain build; by silently I mean automatically > > > > > appended to $LFS without knowing when/where so it won't error out), > > > > > but wouldn't specifying correct flags when configuring GCC, binutils > > > > > and Glibc remove the need for such symlink? > > > > No, unless we use some DESTDIR installation. It's Pierre's cross Chapter 5 > > experiment: > > > > http://www.linuxfromscratch.org/~pierre/lfs-modified/ > > > > I've checked piere's modifications, and they're most welcome, but I'm > only talking about removing the `/tools` symlink without touching > anything else. > > I don't think GCC needs its source modifications be changed (meaning > that we'll still use the regular `/tools/lib`), and I think that's > made possible because sysroot is actually appended before ld's search > path (one thing that might require minor modification is that when ld > inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying > `t-linux64` to use `../lib` instead of `../lib64`) path relative to > where it is, it won't get the right `lib` folder as it gets to > `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the > configuration passed to the toolchain components. It's not about library search path. It's about GCC internal executable path. When you configure GCC with --prefix=/mnt/lfs/tools, the path "/mnt/lfs/tools/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/" gets hardcoded into executables gcc, g++, etc. When this GCC build is used, it searches internal executables cc1, cc1plus, etc. in this path. So if we use -- prefix=/mnt/lfs/tools for GCC pass 2, it will be unusable at all in chroot (gcc will say something like 'cc1 not found'). And there is a GCC library path "/mnt/lfs/tools/lib/gcc/x86_64-linux-gnu/10.1.0" contains libgcc libraries and headers. It's also hardcoded. One way to solve this is to add CC="gcc -B /tools/libexec/gcc/x86_64-linux- gnu/10.1.0 -L /tools/lib/gcc/x86_64-linux-gnu/10.1.0 -I /tools/lib/gcc/x86_64- linux-gnu/10.1.0/include" in early Chapter 6 packages. I believe such a long $CC is stupid. Another way, already said by Pierre, is "ln -sv /tools /mnt/lfs" in chroot environment. > > > > > These errors can be evaded by closely examining > > > > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > > > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > > > > > to "../../lib" based on where ld is searching), along with > > > > > `--with-lib-path` in binutils pass 1. > > > > > > > > > > I'm curious to hear your thoughts on the matter. > > > > > > > > > > Thanks for your time and effort. > > > > > > > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > > > > we have /tools. But then, when going to chapter 6, some search paths > > > > would contain $LFS/tools, that we do not have in chroot. That's the > > > > reason to have the link and use it in chapter 5. > > > > > > > > > > > > Note, we could maybe create /mnt/lfs in chroot, and have: > > > > /mnt/lfs/tools->/tools in chroot. > > > > Never tried. > > > > > > > > Pierre > > > > > > > > > > > > -- > > > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > > > FAQ: http://www.linuxfromscratch.org/faq/ > > > > Unsubscribe: See the above information page > > > > > > I understand that due to chroot environment $LFS/tools will eventually > > > become /tools and the path to the link inside every binary produced in > > > Chapter 5 (due to the modification of the GCC sources) will thus > > > remain valid inside chroot, but wouldn't it be better to spare the > > > host system? > > > > Now we know it works well. And we know there is no other packages using > > /tools > > (we've discussed this in
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On Sat, May 16, 2020 at 4:19 AM Xi Ruoyao via lfs-dev wrote: > > On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > > wrote: > > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > > wrote: > > > > Hey there, > > > > > > > > I'd like to inquire about the actual need for the /toolchain symlink > > > > on the host system. > > > > > > > > Apparently, failure to create this link causes > > > > configure/build/linking > > > > problems starting from Chapter's 5 libstdc++ with errors in the form > > > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > > > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > > > > > > > I'm not really sure why this link is required though. I understand > > > > that it's currently a must to build LFS (apparently not much > > > > explanation is provided to how GCC/Binutils searching/configuring > > > > works with regards to directory layout,so we need to cover for > > > > $LFS/tools and /tools with the latter being silently used in some > > > > places to make the toolchain build; by silently I mean automatically > > > > appended to $LFS without knowing when/where so it won't error out), > > > > but wouldn't specifying correct flags when configuring GCC, binutils > > > > and Glibc remove the need for such symlink? > > No, unless we use some DESTDIR installation. It's Pierre's cross Chapter 5 > experiment: > > http://www.linuxfromscratch.org/~pierre/lfs-modified/ > I've checked piere's modifications, and they're most welcome, but I'm only talking about removing the `/tools` symlink without touching anything else. I don't think GCC needs its source modifications be changed (meaning that we'll still use the regular `/tools/lib`), and I think that's made possible because sysroot is actually appended before ld's search path (one thing that might require minor modification is that when ld inside /tools/$LFS_TGT/bin tries to get the `../lib` (after modifying `t-linux64` to use `../lib` instead of `../lib64`) path relative to where it is, it won't get the right `lib` folder as it gets to `/tools/$LFS_TGT/lib` when it should've been `/tools/lib` based on the configuration passed to the toolchain components. > > > > These errors can be evaded by closely examining > > > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > > > > to "../../lib" based on where ld is searching), along with > > > > `--with-lib-path` in binutils pass 1. > > > > > > > > I'm curious to hear your thoughts on the matter. > > > > > > > > Thanks for your time and effort. > > > > > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > > > we have /tools. But then, when going to chapter 6, some search paths > > > would contain $LFS/tools, that we do not have in chroot. That's the > > > reason to have the link and use it in chapter 5. > > > > > > > > > Note, we could maybe create /mnt/lfs in chroot, and have: > > > /mnt/lfs/tools->/tools in chroot. > > > Never tried. > > > > > > Pierre > > > > > > > > > -- > > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > > FAQ: http://www.linuxfromscratch.org/faq/ > > > Unsubscribe: See the above information page > > > > I understand that due to chroot environment $LFS/tools will eventually > > become /tools and the path to the link inside every binary produced in > > Chapter 5 (due to the modification of the GCC sources) will thus > > remain valid inside chroot, but wouldn't it be better to spare the > > host system? > > Now we know it works well. And we know there is no other packages using > /tools > (we've discussed this in lfs-dev long times ago). /tools is a simple symlink > in > host so it's easy to remove. > I don't think it's as simple as you've mentioned, many users have reported problems when doing the exact same steps in LFS but without creating the `/tools` symlink, here's one I found recently: https://stackoverflow.com/questions/59705962/ld-fails-to-find-libc-when-compiling-first-pass-of-cross-gcc If it were simple, can you please provide instructions on how to "not create" this symlink for users who don't want to pollute their host system? > > Also I apologize for the error in the name of this message as it's > > supposed to be /tools and not /toolchain. > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page Thanks again! -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On 2020-05-15 19:28 +0300, Firas Khalil Khana via lfs-dev wrote: > On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev > wrote: > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > > wrote: > > > Hey there, > > > > > > I'd like to inquire about the actual need for the /toolchain symlink > > > on the host system. > > > > > > Apparently, failure to create this link causes > > > configure/build/linking > > > problems starting from Chapter's 5 libstdc++ with errors in the form > > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > > > > > I'm not really sure why this link is required though. I understand > > > that it's currently a must to build LFS (apparently not much > > > explanation is provided to how GCC/Binutils searching/configuring > > > works with regards to directory layout,so we need to cover for > > > $LFS/tools and /tools with the latter being silently used in some > > > places to make the toolchain build; by silently I mean automatically > > > appended to $LFS without knowing when/where so it won't error out), > > > but wouldn't specifying correct flags when configuring GCC, binutils > > > and Glibc remove the need for such symlink? No, unless we use some DESTDIR installation. It's Pierre's cross Chapter 5 experiment: http://www.linuxfromscratch.org/~pierre/lfs-modified/ > > > These errors can be evaded by closely examining > > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > > > to "../../lib" based on where ld is searching), along with > > > `--with-lib-path` in binutils pass 1. > > > > > > I'm curious to hear your thoughts on the matter. > > > > > > Thanks for your time and effort. > > > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > > we have /tools. But then, when going to chapter 6, some search paths > > would contain $LFS/tools, that we do not have in chroot. That's the > > reason to have the link and use it in chapter 5. > > > > > > Note, we could maybe create /mnt/lfs in chroot, and have: > > /mnt/lfs/tools->/tools in chroot. > > Never tried. > > > > Pierre > > > > > > -- > > http://lists.linuxfromscratch.org/listinfo/lfs-dev > > FAQ: http://www.linuxfromscratch.org/faq/ > > Unsubscribe: See the above information page > > I understand that due to chroot environment $LFS/tools will eventually > become /tools and the path to the link inside every binary produced in > Chapter 5 (due to the modification of the GCC sources) will thus > remain valid inside chroot, but wouldn't it be better to spare the > host system? Now we know it works well. And we know there is no other packages using /tools (we've discussed this in lfs-dev long times ago). /tools is a simple symlink in host so it's easy to remove. > Also I apologize for the error in the name of this message as it's > supposed to be /tools and not /toolchain. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On Fri, May 15, 2020 at 6:48 PM Pierre Labastie via lfs-dev wrote: > > On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev > wrote: > > Hey there, > > > > I'd like to inquire about the actual need for the /toolchain symlink > > on the host system. > > > > Apparently, failure to create this link causes > > configure/build/linking > > problems starting from Chapter's 5 libstdc++ with errors in the form > > of failure to perform sanity checks (mostly because cpp's (gcc -E) > > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > > > I'm not really sure why this link is required though. I understand > > that it's currently a must to build LFS (apparently not much > > explanation is provided to how GCC/Binutils searching/configuring > > works with regards to directory layout,so we need to cover for > > $LFS/tools and /tools with the latter being silently used in some > > places to make the toolchain build; by silently I mean automatically > > appended to $LFS without knowing when/where so it won't error out), > > but wouldn't specifying correct flags when configuring GCC, binutils > > and Glibc remove the need for such symlink? > > > > These errors can be evaded by closely examining > > `--with-native-system-header-dir` and `--with-sysroot` starting from > > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > > to "../../lib" based on where ld is searching), along with > > `--with-lib-path` in binutils pass 1. > > > > I'm curious to hear your thoughts on the matter. > > > > Thanks for your time and effort. > > Chapter 5 is not the problem: we could change to $LFS/tools everywhere > we have /tools. But then, when going to chapter 6, some search paths > would contain $LFS/tools, that we do not have in chroot. That's the > reason to have the link and use it in chapter 5. > > > Note, we could maybe create /mnt/lfs in chroot, and have: > /mnt/lfs/tools->/tools in chroot. > Never tried. > > Pierre > > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page I understand that due to chroot environment $LFS/tools will eventually become /tools and the path to the link inside every binary produced in Chapter 5 (due to the modification of the GCC sources) will thus remain valid inside chroot, but wouldn't it be better to spare the host system? Also I apologize for the error in the name of this message as it's supposed to be /tools and not /toolchain. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Why is the /toolchain symlink on the host system even needed?
On Fri, 2020-05-15 at 18:21 +0300, Firas Khalil Khana via lfs-dev wrote: > Hey there, > > I'd like to inquire about the actual need for the /toolchain symlink > on the host system. > > Apparently, failure to create this link causes > configure/build/linking > problems starting from Chapter's 5 libstdc++ with errors in the form > of failure to perform sanity checks (mostly because cpp's (gcc -E) > include paths are wrong), ld not finding crt1.o, crti.o, and so on... > > I'm not really sure why this link is required though. I understand > that it's currently a must to build LFS (apparently not much > explanation is provided to how GCC/Binutils searching/configuring > works with regards to directory layout,so we need to cover for > $LFS/tools and /tools with the latter being silently used in some > places to make the toolchain build; by silently I mean automatically > appended to $LFS without knowing when/where so it won't error out), > but wouldn't specifying correct flags when configuring GCC, binutils > and Glibc remove the need for such symlink? > > These errors can be evaded by closely examining > `--with-native-system-header-dir` and `--with-sysroot` starting from > GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command > to "../../lib" based on where ld is searching), along with > `--with-lib-path` in binutils pass 1. > > I'm curious to hear your thoughts on the matter. > > Thanks for your time and effort. Chapter 5 is not the problem: we could change to $LFS/tools everywhere we have /tools. But then, when going to chapter 6, some search paths would contain $LFS/tools, that we do not have in chroot. That's the reason to have the link and use it in chapter 5. Note, we could maybe create /mnt/lfs in chroot, and have: /mnt/lfs/tools->/tools in chroot. Never tried. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Why is the /toolchain symlink on the host system even needed?
Hey there, I'd like to inquire about the actual need for the /toolchain symlink on the host system. Apparently, failure to create this link causes configure/build/linking problems starting from Chapter's 5 libstdc++ with errors in the form of failure to perform sanity checks (mostly because cpp's (gcc -E) include paths are wrong), ld not finding crt1.o, crti.o, and so on... I'm not really sure why this link is required though. I understand that it's currently a must to build LFS (apparently not much explanation is provided to how GCC/Binutils searching/configuring works with regards to directory layout,so we need to cover for $LFS/tools and /tools with the latter being silently used in some places to make the toolchain build; by silently I mean automatically appended to $LFS without knowing when/where so it won't error out), but wouldn't specifying correct flags when configuring GCC, binutils and Glibc remove the need for such symlink? These errors can be evaded by closely examining `--with-native-system-header-dir` and `--with-sysroot` starting from GCC Pass 1 (along with modifying the "../lib64" t-linux64 sed command to "../../lib" based on where ld is searching), along with `--with-lib-path` in binutils pass 1. I'm curious to hear your thoughts on the matter. Thanks for your time and effort. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
