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...
Well, my guess is that gcc does generate generic debug instructions, even if
if the headers are not used... I felt like glibc would add -nostdinc to
gcc options.
But maybe it does not do that if CC is redefined...
Ah no, it only does that if --with-headers is specified... Maybe we should
use this option (--with-headers=/usr/include).
Pierre
Pierre
We don't have any reference in /lib/libc.so.6 -> libc-2.29.so to tools.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
