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