On Thu, Mar 28, 2019 at 11:42:25PM +0100, Pierre Labastie via lfs-dev wrote: > On 28/03/2019 11:44, Pierre Labastie via lfs-dev wrote: > > On 28/03/2019 10:42, thomas via lfs-dev wrote: > >> Am 2019-03-28 09:57, schrieb Pierre Labastie via lfs-dev: > >>> On 27/03/2019 17:55, Pierre Labastie via lfs-dev wrote: > >>>> On 27/03/2019 16:43, Bruce Dubbs via lfs-dev wrote: > >>>>> On 3/26/19 11:51 PM, DJ Lucas via lfs-dev wrote: > >>>>> > >>>>>> For future reference, the 'strings' utility might be better suited for > >>>>>> this > >>>>>> task, rather than opening a binary in a text editor. > >>>>>> > >>>>>> $ strings /lib/libc.so.6 | grep "tools" > >>>>> > >>>>> Good idea. > >>>>> > >>>>> $ strings /lib/libc-2.29.so.dbg|grep tools > >>>>> /tools/include/bits > >>>>> /tools/include/bits/types > >>>>> /tools/include > >>>> > >>>> I'm still wondering why we have those in glibc. Normally glibc does *not* > >>>> use any header out of /usr/include, even if gcc has default include paths > >>>> in /tools/include. So why have those in the debug info? Of course, it is > >>>> not > >>>> an issue, since the debug info is not used except when trying to debug... > >>>> But understanding why this appears may lead to deeper understanding > >>>> of how to insulate /usr from /tools... > >>>> > > Did some more testing. Summary below. About what is in the above paragraph: > glibc libraries are linked statically to libgcc. Even if anything else in > glibc is made independent on /tools, libgcc was compiled against headers in > /tools, and retains the information... > Summary: > - old method (LFS-8.4): symlink /usr/lib/gcc to /tools/lib/gcc, pass "-isystem > /usr/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include". This > allows using kernel headers in /usr/include. Some headers in /tools are used, > but not many, because one program is compiled with g++, and we have not linked > the c++ headers to /usr. The libraries contain /tools in debug information, > because of the libgcc problem described above. > > - new method (SVN): no symlink. Pass "-ffile-prefix-map=/tools=/usr". The > libraries seem identical to those obtained by the old method, but the kernel > headers are taken from /tools/include. Not a big deal since they should be > identical to those from /usr/include, but not very clean. Who can be sure > those headers have not been modified? > > - new method + pass --with-headers=/usr/include. Gives the same results as the > old method, AFAICT. > > So I'd suggest adding --with-headers=/usr/include to the current instructions. > I can do that if you agree. >
Nice analysis, I'm glad that people are again looking at possible sources of "pollution". But I think we still say that people can tar up /tools before proceding to chroot, and I'm sure I've seen posts on -support where people have done that, but using an _older_ /tools (i.e. to save time they have omitted chapter 5 on the newer build). > A very clean method can be used, but the reference to /tools cannot be removed > (because of the link to libgcc). Here's the method: > symlinks: > /usr/lib/gcc->/tools/lib/gcc > /usr/include/c++->/tools/include/c++ > Don't set CC=, but pass --with-headers. > Then replace "-isystem /tools" with "-isystem /usr" and "/tools/include" with > "/usr/include" in config.make. > > But I do not think this method is worth it... > > Pierre It is disappointing that glibc links to static libgcc. What we really need is a new generation of experimenters to replace Greg and Ryan. I like the sound of the "very clean method", but I'm not sure that it helps, particularly if someone uses an archived old version of tools. But on the other hand, it is possible that I saw actions like that getting mentioned because of problems which resulted, so perhaps anyone doing that will get to keep both the pieces. ĸen > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- It is said that there are two great unsolved problems in computer science: naming, cache invalidation, and off-by-one errors. -- Ben Bullock -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
