On Sat, May 16, 2020 at 6:46 AM Xi Ruoyao via lfs-dev <lfs-dev@lists.linuxfromscratch.org> 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 > > <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? > > 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 "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... > > If you really hate /tools, use /opt/lfs/tools or something. > -- > 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
Sigh... I wish more of this was actually documented when explaining why certain flags are used with regards to what paths are baked to certain executables and why we're going with this approach... 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
