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 <0x66726...@gmail.com> wrote: >>> >>> Hi Pierre, >>> >>> On Fri, Feb 21, 2020 at 11:01 AM Pierre Labastie via lfs-dev >>> <lfs-dev@lists.linuxfromscratch.org> 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 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page