On Sat, May 16, 2020 at 5:48 AM Xi Ruoyao via lfs-dev <lfs-dev@lists.linuxfromscratch.org> 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 > > <lfs-dev@lists.linuxfromscratch.org> 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 > > > > <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/ > > > > > > > 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/ > > > > > 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 > > 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 "arbirarily" changing the package version, and I'm investigating (and documenting) everything I'm encountering. I decided to tackle this `/tools` symlink and I'm trying to wrap my head around its actual need at this point with the little documentation available about how binary/include/lib paths work in a toolchain. > "/achm" is as good (or "bad") as "/tools". Just some non-FHS directories > nobody > uses. If you want to be "good" (FHS-compliant) use something like > "/var/lib/lfs/tools", or "/opt/lfs/tools". > > > 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? > > Nobody except LFS uses /tools. So it's not a polluation. > I'm not saying that other projects are using `/tools` (many LFS derived projects do though...), what I meant by polluting is creating an additional symlink in the root directory of your 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 <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 > > > > Thanks again! > -- > 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 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
