lfs-book, version 6.4, chapter 6.7, "make: gcc: Command not found"

Aaron Schawalder mygcc at gmx.ch
Sat Feb 14 14:24:35 PST 2009


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:
>>
>> lfs at esprit:~$ echo $LFS
>> /mnt/lfs
>> lfs at esprit:~$ echo $PATH
>> /tools/bin:/bin:/usr/bin
>> lfs at 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:
>> lfs at esprit:/mnt/lfs/tools$ echo 'main(){}' > dummy.c
>> lfs at esprit:/mnt/lfs/tools$ cc dummy.c
>> lfs at esprit:/mnt/lfs/tools$ readelf -l a.out | grep ': /tools'
>>       [Requesting program interpreter: /tools/lib/ld-linux.so.2]
>>
>> and
>>
>> lfs at 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:
>>
>> lfs at 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.



More information about the lfs-support mailing list