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:
>> On 2020-02-20 22:05 -0600, Bruce Dubbs via lfs-dev wrote:
>>> On 2/20/20 6:57 PM, Xi Ruoyao via lfs-dev wrote:
>>>> On 2020-02-21 01:54 +0100, Tadeus Prastowo via lfs-dev wrote:
>>>>> Hello,
>>>>>
>>>>> To quote
>>>>> http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pass2.html
>>>>>
>>>>> :
>>>>>
>>>>> --with-sysroot
>>>>> The sysroot feature enables the linker to find shared objects which
>>>>> are required by other shared objects explicitly included on the
>>>>> linker's command line. Without this, some packages may not build
>>>>> successfully on some hosts.
>>>>>
>>>>> End quote.
>>>>>
>>>>> As described in another e-mail at
>>>>> http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-February/073506.html,
>>>>>
>>>>> the `--with-sysroot' option used to configure the second binutils will
>>>>> refer to a non-existent directory, such as
>>>>> /LFS-tools/x86_64-pc-linux-gnu/sys-root/.  In other words, it cannot
>>>>> be the case that the linker (ld) will "find shared objects which are
>>>>> required by other shared objects explicitly included on the linker's
>>>>> command line" in the non-existent directory.  While it is true that
>>>>> "without this, some packages may not build successfully on some hosts"
>>>>> (e.g., the first build of Perl), the description of the
>>>>> `--with-sysroot' can be improved as follows:
>>>>>
>>>>> This option will prevent the linker from looking in the default places
>>>>> in the build system (e.g., by reading the file /etc/ld.so.conf) by
>>>>> forcing the linker to look only in places within the non-existent
>>>>> default sysroot directory /tools/$LFS_TGT/sys-root.  If this option is
>>>>> not given and the linker reads some working ld.so.conf of the build
>>>>> system, the linker will produce objects that are linked to the build
>>>>> system's library, not to the libraries built within the /tools
>>>>> directory, which defeats the effort of having a clean build.
>>>>>
>>>>> What do you think?  Thanks.
>>>>
>>>> I agree.  This also confused me when I was doing the Chinese translation.
>>>
>>> I think we can improve the wording here, bu tnote that the linker
>>> actually looks at ld.so.cache, not ld.so.conf.  Only the ldconfig
>>> command looks at ld.so.conf.
>>
>> 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. The
--with-sysroot switch has not effect if ld is called without -rpath option...
Let me try with my non-native English:
This option will change the linker behavior when it is run with a command
containing the -rpath switch: any linked library will be searched into the
path specified by -rpath before searching other locations such as
/etc/ld.so.conf. Note that since the default sysroot location does not exist,
it does not intervene in the searching process. Without the --with-sysroot
option, the -rpath path is not used for searching dependent libraries, with
the risk of finding host libraries, which defeats the effort of having a clean
build.

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to