Chris Staub wrote:
> Aaron Schawalder wrote:
>
>>>> Something is wrong ...
>>>>
>>>> I performed the following tests:
>>>> /home/lfs is the home directory of user "lfs"
>>>>
>>>> root:/sources/linux-2.6.27.4# exit
>>>> logout
>>>> esprit:/home/lfs# echo $LFS
>>>> /mnt/lfs
>>>> esprit:/home/lfs# readelf -l /tools/bin/gcc | grep interpret
>>>> [Requesting program interpreter: /lib/ld-linux.so.2]
>>>> esprit:/home/lfs#
>>>>
>>>>
>>> I don't see the point of this. You're neither the lfs user nor inside
>>> chroot - this is just as a regular user, so you're only testing the host
>>> system's gcc.
>>>
>>>
>>>
>> The point here is, that I was user "lfs" and went "su" and performed
>> "readelf -l /tools/bin/gcc | grep interpret". So I performed the readelf
>> for /tools/bin/gcc as root but not in chroot.
>>
>>
>
> Ah, you'd lost me in all the extraneous info you've given. You *did* do
> readelf /tools/bin/gcc. It doesn't make the slightest difference which
> user you did that as or whether or not you were in chroot - that output
> indicates that /tools/bin/gcc is in fact linked wrong, so you do need to
> start over.
>
Ok, that's bad. I dodn't know where the bug occured ...
>>>>
>>>>
>>> Obviously "cc" isn't going to be found if /tools/bin isn't in the PATH.
>>>
>>>
>> When I am logged in as user "lfs" and I am not in the chroot
>> environment, I get:
>>
>> l...@esprit:~$ echo $LFS
>> /mnt/lfs
>> l...@esprit:~$ echo $PATH
>> /tools/bin:/bin:/usr/bin
>> l...@esprit:~$
>>
>> So the PATH here is correct.
>>
>>
>
> I never asked about the PATH, nor did I say anything about the ownership
> of /tools/bin. Besides, you're just repeating a bunch of stuff you've
> said before.
>
Yes you never asked about the PATH but I wondered if there could be a
problem with the PATH for gcc and cc were not found.
Yes I repeated stuff for I was not sure if you understood what I did.
>> [As I mentioned: At the end of the second path of gcc (chapter 5.12) I get:
>> l...@esprit:/mnt/lfs/tools$ echo 'main(){}' > dummy.c
>> l...@esprit:/mnt/lfs/tools$ cc dummy.c
>> l...@esprit:/mnt/lfs/tools$ readelf -l a.out | grep ': /tools'
>> [Requesting program interpreter: /tools/lib/ld-linux.so.2]
>>
>> and
>>
>> l...@esprit:/mnt/lfs/tools$ readelf -l a.out
>>
>> Elf file type is EXEC (Executable file)
>> ....
>> INTERP 0x000114 0x08048114 0x08048114 0x00019 0x00019 R 0x1
>> [Requesting program interpreter: /tools/lib/ld-linux.so.2]
>> ]
>>
>>
>
> That indicates that *binaries built by /tools/bin/gcc* are linked
> correctly, but that's different from /tools/bin/gcc itself, which, as
> above output indicates, is not linked right.
>
Sorry, I don't get the point. What difference do you mean?
>> Then I go su because I can do chroot only as root:
>>
>> l...@esprit:~$ su
>> Password:
>> esprit:/home/lfs#
>>
>>
>
> We do not need a complete record of each and every single solitary
> command you do. This just takes up space and makes it much more
> difficult to follow what you are trying to say.
>
Ok. I just thought that this would help to solve the problem.
>>> readelf -l /tools/bin/gcc | grep interpret
>>>
>>> My guess is it will say /lib, not /tools/lib.
>>>
>> No because als user "lfs" (not in chroot environment), it was /tools/lib
>> as you see above.
>>
>>
>>> If so, gcc is linked
>>> wrong, in which case my guess would be that you forgot to rm the source
>>> and/or build dirs for gcc in between pass 1 and pass 2.
>>>
>> No I didn't forgot this. I always removed the sources before performing
>> the next step.
>>
>>
> You said "the sources". Does that also include the build directories
> (gcc-build, binutils-build, etc...)?
>
Yes of course.
Since there is a serious problem with the toolchain (wherefrom is not
clear) I will start all over again.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
