How to resolve error when creating full internal limits.h header after compiling cross gcc?

gegorg · 09-26-2022, 05:32 PM

Hello forum members,

today I started getting into LFS but unfortunately, at the end of 'Installation of Cross GCC' (5.3.1) I ended up with an error that I do not know how to resolve.

I followed these instructions in 5.3.1:

Quote:

This build of GCC has installed a couple of internal system headers. Normally one of them, limits.h, would in turn include the corresponding system limits.h header, in this case, $LFS/usr/include/limits.h. However, at the time of this build of GCC $LFS/usr/include/limits.h does not exist, so the internal header that has just been installed is a partial, self-contained file and does not include the extended features of the system header. This is adequate for building glibc, but the full internal header will be needed later. Create a full version of the internal header using a command that is identical to what the GCC build system does in normal circumstances:

Code:

cd ..
cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \
  `dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/install-tools/include/limits.h

This happens when I try it:

Code:

lfs:/mnt/lfs/sources/gcc-12.2.0$ cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \
  `dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/install-tools/include/limits.h

And I get this error:

Code:

bash: x86_64-lfs-linux-gnu-gcc: command not found
dirname: missing operand
Try 'dirname --help' for more information.
bash: /install-tools/include/limits.h: No such file or directory

I already tried just running:

Code:

lfs:/mnt/lfs/sources/gcc-12.2.0$ $(dirname $($LFS_TGT-gcc -print-libgcc-file-name))

and I get the same error:

Code:

bash: x86_64-lfs-linux-gnu-gcc: command not found
dirname: missing operand
Try 'dirname --help' for more information.

I am using a Fedora 36 liveCD as my host system, in virtualbox and everything seems to be fine when I run the version-check.sh from the system requirements chapter

The same issue came up here, but has not really been resolved anywhere (other than going back to chapter 4):

I hope you can help me out, I'm still figuring things out here

wiigelec · 09-27-2022, 10:42 AM

what is the output of echo $LFS_TGT?

edit: sorry that looks ok but it looks like the tools dir isn’t in your path which is why it can’t find x86_64-lfs-linux-gnu-gcc

edit again: what does your .bashrc file look like? have you run source ~/.bash_profile?

https://www.linuxfromscratch.org/lfs...vironment.html

gegorg · 09-28-2022, 03:55 AM

sorry for the late reply.

Here is my $LFS_TGT, $PATH and .bashrc:

Code:

lfs:/mnt/lfs/sources/gcc-12.2.0$ echo $LFS_TGT 
x86_64-lfs-linux-gnu
lfs:/mnt/lfs/sources/gcc-12.2.0$ echo $PATH
/mnt/lfs/tools/bin:/usr/bin
lfs:/mnt/lfs/sources/gcc-12.2.0$ cat ~/.bashrc
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
lfs:/mnt/lfs/sources/gcc-12.2.0$ cat ~/.bash_profile 
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash

and yes, I have run

Code:

source ~/.bash_profile

, but it didn't change anything.

edit: okay, so I checked my /mnt/lfs/tools/bin/ and there is in fact no x86_64-lfs-linux-gnu-gcc:

Code:

lfs:/mnt/lfs/sources/gcc-12.2.0$ ls /mnt/lfs/tools/bin/
x86_64-lfs-linux-gnu-addr2line	x86_64-lfs-linux-gnu-elfedit  x86_64-lfs-linux-gnu-nm	    x86_64-lfs-linux-gnu-readelf
x86_64-lfs-linux-gnu-ar		x86_64-lfs-linux-gnu-gprof    x86_64-lfs-linux-gnu-objcopy  x86_64-lfs-linux-gnu-size
x86_64-lfs-linux-gnu-as		x86_64-lfs-linux-gnu-ld       x86_64-lfs-linux-gnu-objdump  x86_64-lfs-linux-gnu-strings
x86_64-lfs-linux-gnu-c++filt	x86_64-lfs-linux-gnu-ld.bfd   x86_64-lfs-linux-gnu-ranlib   x86_64-lfs-linux-gnu-strip

That might be a problem

I am debating just starting all over again.

hazel · 09-28-2022, 05:38 AM

Well, if it isn't there, you didn't install it. All the programs I can see in that directory belong to the binutils package. I suppose you could try going back to the gcc/build directory and running make install again (repeating make install never does any harm), then try creating the header. If that works, carry on. If not, start again.