On 25/03/2019 16:05, Bruce Dubbs via lfs-dev wrote:
On 3/25/19 8:12 AM, Pierre Labastie via lfs-dev wrote:
On 25/03/2019 10:34, Xi Ruoyao via lfs-dev wrote:
On 2019-03-24 12:49 -0500, Bruce Dubbs via lfs-dev wrote:
On 3/24/19 12:20 PM, Xi Ruoyao via lfs-dev wrote:
In r11250 DJ introduced several symlinks and GCC -isystem options
for Glibc
so
it will use the final system location of system headers. When I
was poking
around Debian package build processes I found they were using
-ffile-prefix-
map
to complete this goal.
This has serveral advantages:
1. The instruction is simpler.
2. No risk of forgetting to remove the symlinks.
3. No /usr/include/limits.h issue.
Is this OK to be commited into the trunk?
It looks OK to me. Go ahead. After you do, I will do a complete
build
and double check. I wan tot update the kernel and iproute anyway.
Commited at r11560.
The commit did not go to the list. It should be fixed now.
Just built a new LFS (overwriting my old LFS 8.1)
to make
sure it works.
Strange thing: both methods (-isystem and -ffile-prefix-map) still
left a few
paths beginning with /tools/include. Open libc.so with vim, search
"/tools",
then we can see them. I'm not sure why.
I'm not sure either, but, according to the doc, the mapping is done
in very specific cases:
- first, it is when compiling a file _residing_ in the old directory
(here, /tools).
Then any reference to the old directory is replaced by the new
directory
(here, /usr) in the _result_ of the compilation.
- second, only two types of substitutions are made: (i) in debugging
information,
and (ii) when processing the "__FILE__" and "__BASE_FILE" macros,
and also
"__builtin_FILE()" function during compilation.
So it seems that any other reference to /tools is likely to remain,
in particular,
if a function whose source resides outside /tools, somehow references
/tools
What I found in an 8.4 build in libc-2.29.so.dbg is:
./../../libgcc^@/mnt/lfs/sources/gcc-8.2.0/build/gcc/include^@
/tools/include/bits^@
/tools/include/bits/types^@
/tools/include^@
../../../libgcc/../include^@
../.././gcc^@
../../../libgcc/../gcc/config/i386^@^@
libgcc2.c^@
^A^@^@
stddef.h^@^B^@^@
types.h^@^C^@^@
struct_FILE.h^@^D^@^@
FILE.h^@^D^@^@
stdio.h^@^E^@^@
sys_errlist.h^@^C^@^@
errno.h^@^E^@^@
unistd.h^@^E^@^@
getopt_core.h^@^C^@^@
time.h^@^E^@^@
hashtab.h^@^F^@^@
insn-constants.h^@^G^@^@
i386.h^@^H^@^@
i386-opts.h^@^H^@^@
libgcc2.h^@
Where ^@ is the null character. There were no reference to tools in
libc-2.29.so.
It looks like that retains some of the build characteristics for
debugging only.
Hmm, had you stripped the debug symbols at the end of chapter 5? I can't
understand how glibc in chapter 6 could know the /mnt/lfs/sources/...
directory. So it looks like a leftover from libgcc. I may be wrong, though.
To Xi Ruoyao: I did not mean that the new method is worse than the
previous. I just tried to find an explanation. Using gcc new options is
the way to go, if they do what we want...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
