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. 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
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
