[lfs-support] LFS8.1 chapter 5.10 : /tools/bin/gcc is dynamically linked to host linker

Pierre Labastie pierre.labastie at neuf.fr
Sun Jul 1 12:53:57 PDT 2018


On 01/07/2018 19:52, Bruce Dubbs wrote:
> On 07/01/2018 09:02 AM, Mohamed Dawod wrote:
>> YES, I removed the build and source dirs after compile ( I need to know why
>> this is mandatory ? )
> 
> Because we build packages multiple times and the old source directory is
> compromised from the previous build.  Deleting and extracting ensures you
> start with a clean source directory.  A side effect is that it also saves
> space on the /mnt/lfs partition.
> 
>> and I made sure that seds in gcc pass1 worked well, I opened the effected
>> files and noticed the differences between the new files and the original
>> files as required
>> BUT.. the only not effected line is that line =(( #define
>> GLIBC_DYNAMIC_LINKERX32 "/libx32/ld-linux-x32.so.2" ))
>> NOTE : my host system is UBUNTU-14.4 LTS
> 
> I am not sure where you found GLIBC_DYNAMIC_LINKERX32.  We do not mention it
> in the book or in the patches.
> 
> What is the output of "ldd --version | head -n1" on the host system?
> 
>>     On 1.7.2018. 10:15, Mohamed Dawod wrote:
>>
>>
>>         HI,
>>
>>         I hope that some one can help me..
>>         This is the 8th time i restart LFS building from chapter3 !!
>>
>>         The problem starts to appear in chapter6.7 (Linux-4.12.7 API
>>         Headers)
>>         (/tools/bin/gcc file doesnt exist error)
>>
>>         The problem is explained in details here :
>>        
>> http://archive.linuxfromscratch.org/mail-archives/lfs-support/2016-February/049686.html
>>
> 
>>
>>         So, I restart from chapter5 and when I reached to  section 5.10.
>>         (GCC-7.2.0 - Pass 2) , I tried to check the linking of
>>         /tools/bin/gcc   using the command
>>
>>         $readelf -l /tools/bin/cc | grep "interpreter"
>>         --The result :
>>         [Requesting program interpreter: /lib/ld-linux.so.2]
>>         __________________________________
>>         The path for my lfs usr :  $echo $PATH
>>         --The result :   /tools/bin:/bin:/usr/bin
>>         __________________________________
>>         The environmental variables for lfs usr : $env|sort
>>         --The result :
>>         HOME=/home/lfs
>>         LC_ALL=POSIX
>>         LFS=/mnt/lfs
>>         LFS_TGT=i686-lfs-linux-gnu
>>         OLDPWD=/mnt/lfs
>>         PATH=/tools/bin:/bin:/usr/bin
>>         PS1=${debian_chroot:+($debian_chroot)}\u@\h:\w\$
>>         PWD=/home/lfs
>>         SHLVL=1
>>         TERM=xterm
>>         _=/usr/bin/env
> 
> The above tells me you are building using a 32-bit host OS.
> I have not done that for a few years now since I no longer have any 32-bit
> systems.  Perhaps the following may be helpful:
> 
> In Section 5.7. Glibc-2.27. does the output of the check in the caution block
> give "/tools/lib/ld-linux.so.2"?
> 
> In section 5.10. GCC-8.1.0 - Pass 2, does the output of
> the check in the caution block give "/tools/lib/ld-linux.so.2"?  I see from
> the above, tha tit does not, do the problem is before is in the initial
> packages.  Do not do beyond 5.10 until the output of the above is correct.
> 
> The PS1 variable above is confusing. When you change to the lfs user, (su -
> lfs), the startup file .bash_profile should set PS1 to "\u:\w\$ '.  The
> debian_chroot should not show up in PS1.

It shows up for me too, even after doing "source .bash_profile". I think
debian sets this in /etc/bash.bashrc, which is executed at startup, according
to "man bash".

Pierre



More information about the lfs-support mailing list