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 > <lfs-dev@lists.linuxfromscratch.org> 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 <xry...@mengyan1223.wang> 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
