On 29/03/2019 00:19, Bruce Dubbs via lfs-dev wrote: > On 3/28/19 5:42 PM, 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. > > I'm not following. What difference does --with-headers=/usr/include make in > the now (current svn) method? >
The current svn method uses the kernel headers from /tools, not those just installed in /usr... Furthermore, after sleeping on it, I'm almost sure the -ffile-prefix-map=/tools=/usr does not add anything, if --with-headers is used (have to test)... Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
