Le 22/02/2020 à 23:04, Pierre Labastie via lfs-dev a écrit : > Le 21/02/2020 à 21:50, Pierre Labastie via lfs-dev a écrit : >> Le 21/02/2020 à 18:15, Tadeus Prastowo a écrit : >>> Some corrections below, keeping in mind that the binutils build is a >>> native build, not a cross build. >>> >>> On Fri, Feb 21, 2020 at 6:05 PM Tadeus Prastowo <[email protected]> >>> wrote: >>>> >>>> Hi Pierre, >>>> >>>> On Fri, Feb 21, 2020 at 11:01 AM Pierre Labastie via lfs-dev >>>> <[email protected]> wrote: >>>>> >>>>> Le 21/02/2020 à 05:33, Bruce Dubbs via lfs-dev a écrit : >>>>>> On 2/20/20 10:09 PM, Xi Ruoyao via lfs-dev wrote: >>>>>>> No. The linker (/usr/bin/ld) looks at ld.so.conf, but the dynamic >>>>>>> linker >>>>>>> (/lib/ld-linux-x86-64.so.2) looks at ld.so.cache. >>>>>> >>>>>> You're right. I got the tools mixed up. Thanks. >>>>>> >>>>>> -- Bruce >>>>>> >>>>>>>> I'll use the above to try to reword the explanation of the >>>>>>>> --with-sysroot option. >>>>> >>>>> Actually, the main use of the --with-sysroot switch is that it changes the >>>>> behavior of ld with respect to the -rpath switch. From man ld: >>>>> >>>>> The linker uses the following search paths to locate required >>>>> shared libraries: >>>>> >>>>> 1. Any directories specified by -rpath-link options. >>>>> >>>>> 2. Any directories specified by -rpath options. The >>>>> difference >>>>> between -rpath and -rpath-link is that directories >>>>> specified by >>>>> -rpath options are included in the executable and used at >>>>> runtime, whereas the -rpath-link option is only effective >>>>> at >>>>> link time. Searching -rpath in this way is only supported >>>>> by >>>>> native linkers and cross linkers which have been configured >>>>> with the --with-sysroot option. >>>>> >>>>> So I think "-rpath" should appear somewhere in this explanation. >>>> >>>> But, pay attention to the following passage: "Searching -rpath in this >>>> way [(i.e., any directories specified by -rpath options)] is only >>>> supported by [...] cross linkers which have been configured with the >>>> --with-sysroot option." It means that, if the `--with-sysroot' option >>>> is not given to configure binutils, the resulting ld will ignore any >>>> -rpath given in the command line. This means that not specifying the >>>> `--with-sysroot' option is indeed a good idea because any path >>>> specified using the `-rpath' option will simply be ignored, keeping >>>> the /tools isolated from the build system. >> >> That's exactly the converse: it's gcc which sets -rpath to the directories >> that should be searched, and gcc knows that it should look for dependent >> libraries in /tools. >> >>> >>> No, the `-rpath' option is not ignored because the problem at hand is >>> building a native binutils. >>> >>>>> The --with-sysroot switch has not effect if ld is called without -rpath >>>>> option... >>>> >>>> That's not true for the problem at hand because the `--with-sysroot' >>>> switch indeed has an effect as already reported in the other thread >>>> despite the absent of the `-rpath' option in the linking command. >>> >>> This stands correct. The `--with-sysroot' option has an effect even >>> if ld is called without any `-rpath' option. >>> >>>> And, the problem at hand uses an ld for a static linking to obtain the >>>> perl executable because both the option `-shared' and *.so files are >>>> not specified in the linking command, no? >> >> I'm not sure. First, the errors occur in a linking command using "cc" (that >> is >> gcc), so -rpath is set behind the hood. Second, even when not specifying >> -shared, dependent libraries may be shared... And actually, the problem >> occurs >> in libpthread.so.0. >> > > Err, well, I'm wrong. I think this used to be the case that -rpath was set by > gcc, but not anymore... And your explanation is (almost) right: if > --with-sysroot is set to a non-existent directory, /etc/ld.so.conf is searched > into this directory and not found. Then ld falls back to the SEARCH_DIR path > of the ld script (I think). > When the --with-sysroot switch was added (in 2013 or so), it was to fix a > problem with building "check" in chapter 5 (we do not do that anymore), and > that one was using -rpath. > It's late here now (I've been studying the ld code almost all day), I'll try > to rewrite the explanation tomorrow. > > Pierre >
Done at r11758. I've also filed a bug upstream [1], because IMHO, the documentation is misleading. Pierre [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25588 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
