On 25/03/2019 19:11, Bruce Dubbs via lfs-dev wrote: > On 3/25/19 12:12 PM, 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. >>> >>> >> >> 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... > > I just did a new build and the /tools entries are the same as in lfs-84. > They're only in the libc-2.29.so.dbg file and then all within a couple of > hundred bytes. It's obviously picking up something from the Chapter 5 files > in /tools. I note that doing a grep for /mnt/lfs/tools in chroot /tools finds > 711 (out of 19637) files that match. > > Searching all other directories, I find no other relevant matches for /tools. > > This appears to be a non-issue to me.
I agree, but trying to understand why weird things happen is a way to better know our (and upstream's) build recipes... Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
