On 26/05/2019 08:24, Daniel Milanov wrote:
> On 25.05.19 г. 20:22 ч., Pierre Labastie wrote:
>
>> On 25/05/2019 17:41, Daniel Milanov wrote:
>>> Thank you for responding.
>>>
>>> The output was indeed correct.
>> Please do not top-post. Did you log out and in, between 6.10 and 6.21?
>>
>> There may be some problem with the PATH.
>>> On 25.05.19 г. 17:55 ч., Pierre Labastie wrote:
>>>> On 25/05/2019 15:37, Daniel Milanov wrote:
>>>>> Hey everybody,
>>>>>
>>>>> I have come across what I'm assuming is an incorrect result, after doing
>>>>> the
>>>>> final build of GCC at 6.21, and testing the toolchain with dummy.c
>>>>> |
>>>>> ||readelf -l a.out | grep||': /lib||'| produces no output, instead,
>> Why do you have double `|' (||) in the above?
>>
>> Anyway. Is there a reference to /tools in the output of:
>> /usr/bin/gcc -dumpspecs
>>
>> (for example "/usr/bin/gcc -dumpspecs | grep tool")
>>
>> (typing /usr/bin/gcc avoids PATH problems)
>>
>> Also, I see that you have an old (8.2.0) version of gcc. What is the version
>> of LFS you are building?
>> (sorry for inqiring, but we need this sort of information to be able to (try
>> to) help...)
>>
>> Pierre
>>>>> after
>>>>> inspecting the binary, it seems that the dynamic linker is looked for in
>>>>> '/tools', the temporary toolchain
>>>>>
>>>>> [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
>>>>>
>>>>> All other inspections in the dummy.c build log, are exactly as the book
>>>>> dictates they ought to be.
>>>>>
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/crt1.o succeeded
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/crti.o succeeded
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/crtn.o succeeded
>>>>>
>>>>> #include <...> search starts here:
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
>>>>> /usr/local/include
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
>>>>> /usr/include
>>>>>
>>>>> SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
>>>>> SEARCH_DIR("/usr/local/lib64")
>>>>> SEARCH_DIR("/lib64")
>>>>> SEARCH_DIR("/usr/lib64")
>>>>> SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
>>>>> SEARCH_DIR("/usr/local/lib")
>>>>> SEARCH_DIR("/lib")
>>>>> SEARCH_DIR("/usr/lib");
>>>>>
>>>>> attempt to open /lib/libc.so.6 succeeded
>>>>>
>>>>> found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
>>>>>
>>>>> The final build, tests and installation of glibc went ok, same for gcc.
>>>>>
>>>> What was the output of the sanity check at the end of "6.10 adjusting the
>>>> toolchain"? It should already report the "program interpreter" as
>>>> "/lib64/ld-linux-x86-64.so.2".
>>>>
>>>> Pierre
>
> Apologies!
>
> Indeed I've had to leave the chroot environment and go back to do fixes, but
> PATH is, and has been set to correct values:
>
> |/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin|
And what about "/usr/bin/gcc -dumspecs"?
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
