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

Bruce Dubbs bruce.dubbs at gmail.com
Sun Jul 1 15:35:40 PDT 2018


On 07/01/2018 02:53 PM, Pierre Labastie wrote:
> 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".

There is no mention of /etc/bash.bashrc in the bash man pages, only 
~/.bashrc.

Checking a Debian system, when we run bash it sources /etc/profile and 
on that distro sources /etc/bash.bashrc. I suppose we could add PS1 to 
the lfs user .bashrc for consistency.

   -- Bruce


More information about the lfs-support mailing list