On 29/03/2019 08:37, Pierre Labastie via lfs-dev wrote: > 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)... >
Wrong assumption... -ffile-prefix-map prevents adding /tools/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include to the debug information (many such lines). So the whole process for glibc should be: ----- 1. patch 2. create LSB+compatibility symlinks 3. create "build" directory and change to it 4. "CC=... ../configure ..., adding --with-headers=/usr/include to the svn instructions 6. make 7. etc ----- That is what is in the current SVN with a change to step 4. I think this change is important. Note: even when stripping libgcc_s.so.1 from debug information before building glibc, I've not been able to remove the references to /tools in the resulting libc and libm... there must be another linked library (lib<x>san or libmpx or libquadmath) containing this information... I'm fed up investigating. @ken: libc and libm are linked statically to the *shared* libgcc library. That makes sense, since lib[cm] are associated with the compiler they've been built with: for example if you want to update gcc later on, you do not necessarily want to rebuild glibc for the new compiler, so glibc should keep the old libgcc... (the libgcc API is all but public, so it may change at each version of gcc). Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
