[lfs-support] [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2] LFS 7.8-rc1

Bruce Dubbs bruce.dubbs at gmail.com
Wed Sep 30 14:34:40 PDT 2015


rhubarbpieguy at gmail.com wrote:
> On 09/28/2015 05:00 PM, Bruce Dubbs wrote:
>> rhubarbpieguy at gmail.com wrote:
>>> On 09/28/2015 08:07 AM, Hazel Russman wrote:
>>>> On Mon, 28 Sep 2015 08:04:07 -0500
>>>> rhubarbpieguy at gmail.com wrote:
>>>>
>>>>> I receive [Requesting program interpreter:
>>>>> /tools/lib64/ld-linux-x86-64.so.2] after running the glibc sanity
>>>>> check
>>>>> (5.7. Glibc-2.22 LFS 7.8-rc1).  The documentation indicates the
>>>>> /tools/lib64/ prefix is fine, but I should see ld-linux.so.2 for the
>>>>> remainder.  I included the following in Binutils-2.25.1 - Pass 1.
>>>>>
>>>>>    case $(uname -m) in
>>>>>     x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;
>>>>> esac
>>>>>
>>>>> /lfs/tools/lib64 is linked to lib and
>>>>> /lfs/tools/lib/ld-linux-x86-64.so.2 to ld-2.22.so.  $LFS_TGT is
>>>>> x86_64-lfs-linux-gnu.
>>>>>
>>>>> I'm compiling 7.8 on a box running LFS 7.7.  I see no errors in
>>>>> binutils/gcc pass 1 or with the API headers.
>>>>>
>>>>>
>>>> If you have a 64-bit system, then that is the correct name for the
>>>> linker.
>>>>
>>> Thank you, that makes sense.  However, the documentation doesn't seem to
>>> address that.
>>>
>>>     "Note that /tools/lib, or /tools/lib64 for 64-bit machines appears
>>> as the prefix of the dynamic linker.
>>>
>>>     If the output is not shown as above or there was no output at all,
>>> then something is wrong. Investigate and retrace the steps to find out
>>> where the problem is and correct it. This issue must be resolved before
>>> continuing on."
>>>
>>> As the documentation specifies only the prefix can differ, doesn't that
>>> imply the remainder must include ld-linux.so.2 as the dynamic linker? If
>>> the output is not shown as above is quite specific language. Perhaps
>>> I'm reading it incorrectly.  But should there be two outputs shown, one
>>> for 32-bit and one for 64-bit machines?
>>
>> Yes, I will clarify that.
>>
>>   -- Bruce
>>
>>
>
> That sounds good.  Of the other sections requiring 64-bit clarification,
> the documentation in 6.17 GCC-5.2.0 seems clear:
>
> References to paths that have components with '-linux-gnu' should be
> ignored, but otherwise the output of the last command should be:
> SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32")
> SEARCH_DIR("/usr/local/lib32")
> SEARCH_DIR("/lib32")
> SEARCH_DIR("/usr/lib32")
> SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
>
>   A 64-bit system may see a few different directories. For example, here
> is the output from an x86_64 machine:
> SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
> SEARCH_DIR("/usr/local/lib64")
> SEARCH_DIR("/lib64")
> SEARCH_DIR("/usr/lib64")
> SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
>
> I realize the outputs differ, but separate 64-bit outputs might do the
> job for all applicable chapters.  Just my take.  There may be a better,
> simpler way.

We can't cover every detail. By the time a user gets to Chapter 6, he 
should be able to figure it out.

   -- Bruce




More information about the lfs-support mailing list