On 2019-03-25 18:12 +0100, Pierre Labastie via lfs-dev wrote: > 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. > > > >
/tools/include/bits /tools/include/bits/types /tools/include Yes, these three paths are preserved. I didn't strip libc.so so I can find them in libc.so. > 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. I didn't. I should try it next time. I also believe it's a leftover from libgcc. But I ran to /tools/lib/gcc/x86_64- pc-linux-gnu and searched for a while with no result. > 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... I'm just puzzled why the previous method also leaves these three paths. If the previous method was better I could accept this fact :). I've kept my libc build in /source. It seems only libc.so and ld-2.29.so have paths containing /tools. And, I think they both picked up these paths from librtld.os. I can find the paths in librtld.os but then I can _not_ find them in dependencies of librtld.os. But they can't just arise from nowhere... Go to sleep and will investigate this tomorrow... -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
