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...
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
Did some more testing... Using --with-headers=/usr/include does not
solve the
problem. Actually, I think there is nothing we can do: glibc cannot be
built
without some of the gcc include files, which are located in /tools.
But what worries me is that the linux headers in /usr/include don't
seem to be
used!!! They are taken from /tools (this is with the current book
instructions). What I have done is:
grep -r /asm /sources/glibc-2.29/build | grep /usr
And it returns nothing, while it returns a lot of paths beginning with
/tools.
Those are in ".dt" files, generated by the -MF switch, which records
the
dependencies of compiled files...
Now adding --with-headers=/usr/include to the current instructions,
allows to
use the linux headers in /usr/include. It does not cure the occurence
of
/tools/include in debugging information.
I'll do a test of renaming our /tools to something else. Just to see if
the remaining references to the /tools in question do still refer to
/tools or if they than refer to the new name. Just wondering if that
/tools is "our" /tools ... or does that make no sence at all?
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
