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...
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?
I think it is our /tools. The thing is that, we want to build glibc for
a gcc located in /usr, but we only have a gcc located in /tools (or
whatever it is called). gcc has important headers in
/tools/lib/gcc/x86_64-pc-linux-gnu/<gcc-version>/include{,-fixed}, and
glibc needs some of those headers (stddef.h, etc), to adapt itself to
the compiler. Also, I think limits.h, which is in /tools/include, is
needed by glibc. My guess is that the only way to suppress completely
the occurrence of /tools is to move all the needed headers (how many of
them) to /usr/lib (or make links). That may not be worth it.
But I recommend using the --with-headers=/usr/include switch. Otherwise,
the linux headers in /tools are used. Again, this is not a big issue,
since both set of headers should be the same, but it is not what we want.
Note that, for your experiment, there are a lot of occurrence of /tools
in the book! Good luck:) At some point, I wanted to have a variable for
this directory name in jhalfs, but I gave up...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
