[SOLVED] x86_64-pc-linux-gnu directory in /tools?

dlb101010 · 12-17-2016, 05:27 AM

Finishing through Chapter 5 of LFS 7.10, there is a host target-triplet directory in the /tools directory:

Code:

bin
etc
include
lib
lib64
libexec
sbin
share
var
x86_64-lfs-linux-gnu
x86_64-pc-linux-gnu

Is that normal?

The compiling seems to have been successful, and the book has been followed exactly with the one exception being a reboot of the host between the first and second pass in Chapter 5. However, I checked the env variables after rebooting:

Code:

lfs:/mnt/lfs/tools$ echo $LFS
/mnt/lfs

Here's the version and library check scripts output:

Code:

root@Slackware:~# bash sh-lfs-version-check.sh 
bash, version 4.3.46(1)-release
/bin/sh -> /bin/bash
Binutils: version 2.26.20160125
bison (GNU Bison) 3.0.4
yacc is bison (GNU Bison) 3.0.4
bzip2,  Version 1.0.6, 6-Sept-2010.
Coreutils:  8.25
diff (GNU diffutils) 3.3
find (GNU findutils) 4.4.2
GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.1)
/usr/bin/awk -> /bin/gawk-4.1.3
gcc (GCC) 5.3.0
g++ (GCC) 5.3.0
(GNU libc) 2.23
grep (GNU grep) 2.25
gzip 1.8
Linux version 4.4.38 (root@hive64) (gcc version 5.3.0 (GCC) ) #2 SMP Sun Dec 11 16:18:36 CST 2016
m4 (GNU M4) 1.4.17
GNU Make 4.1
GNU patch 2.7.5
Perl version='5.22.2';
sed (GNU sed) 4.2.2
tar (GNU tar) 1.29
texi2any (GNU texinfo) 6.1
xz (XZ Utils) 5.2.2
g++ compilation OK

root@Slackware:~# bash sh-lfs-library-check.sh 
libgmp.la: found
libmpfr.la: found
libmpc.la: found

Thanks in advance!

hazel · 12-17-2016, 05:49 AM

I've just checked. I have them in my /tools directory too, so they must be normal.

dlb101010 · 12-17-2016, 06:43 AM

Thanks Hazel!

Great to have that reassurance before moving onto chapter 6.

Keeping a close eye on the details makes for a better learning experience, but because I don't fully understand the underlying mechanisms, doing so has the side effect of turning me into a Linux hypochondriac!

Dave

Luridis · 12-20-2016, 02:19 AM

Some of the packages do not need the cross compiler flag target=$LFS_TGT to work properly in /tools, they'll create a directory for whatever their config.guess determines the machine type is, which is usually:

x86_64-unknown-linux-gnu or x86_64-pc-linux-gnu

On a side note: If the "unknown" target triplet annoys you, like it does me. You can copy the config.guess out of the latest binutils and use a simple shell script to copy it from the /sources directory over any internal copies of config.guess that are in the package. Just don't do this for these: gcc,libgmp,libmpfr,libmpc The config.guess files in those packages work differently and effect compile-time stuff.

Assuming you've copied the binutils config.guess to /sources...

Code:

cat > /sources/repl-cfg-guess.sh << "EOF"
for file in $(find -name config.guess)
do
    cp -v ../config.guess $file
done
EOF
chmod a+x /sources/repl-cfg-guess.sh

Then just ../rep<tab> and <enter> from inside a freshly untarred package and you'll see no more "program running on 64-bit UNKNOWN Linux", etc. God, that's annoying at times.

dlb101010 · 12-21-2016, 08:42 AM

Hey Luridis,

If I understand what you're saying, then yes, that would be annoying. After putting effort into making a lfs TGT, I'd be irritated having it called "unknown". Thanks for the suggestion!

Dave

Luridis · 12-21-2016, 01:12 PM

The LFS_TGT variable is the cross compilation target. This just effects what's in the /tools directory. The system target is set when you compile glibc in chapter 6, and the newest glibc's do this correctly.

However, some packages in chapter 6, and on into BLFS will run their own config.guess (an old one) and label your machine a x86_64-unknown-linux-gnu, and may compile that into their executable unless you change them. When that happens you'll occasionally see some program output with that info. So, after GCC in chapter 6 is where I start changing the config.guess files. One post I saw about the "unknown" label explained that someone was having builds fail because the packages were specifically for PC and the configure failed when it saw "unknown". I think they were perl modules.

Anyhow, if you do it, there's no reason to until after GCC in chapter 6. And it should never be done for GCC or GMP, MPFR or MPC. Those work differently and are used to effect their compilation. For instance: If I run GMP's config.guess on this pc it says just "haswell".

dlb101010 · 12-22-2016, 05:54 AM

Thanks for the detailed advice.

I'll check and change the config.guess after GCC in Chapter 6, and also avoid doing so for GMP, MPFR and MPC, but fortunately it'll have to wait for my second run-through because last night I finished LFS (yay!), and have started BLFS. However, I definitely want to redo LFS and have more fun with it the second time around, such as using your suggestions.