On 29/03/2019 11:09, Bruce Dubbs via lfs-dev wrote: > On 3/29/19 4:42 AM, Pierre Labastie via lfs-dev wrote: >> 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). > > I do not agree that removing /tools from debug information is important.
You're missing the point: the change I propose is for *using* the kernel headers in /usr/include. The current SVN uses the kernel headers in /tools/include. I do think it is important... Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
