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. 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 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
