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?
A very clean method can be used, but the reference to /tools cannot be removed
(because of the link to libgcc). Here's the method:
symlinks:
/usr/lib/gcc->/tools/lib/gcc
/usr/include/c++->/tools/include/c++
Don't set CC=, but pass --with-headers.
Then replace "-isystem /tools" with "-isystem /usr" and "/tools/include" with
"/usr/include" in config.make.
But I do not think this method is worth it...
LOL. No, it's not.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
