LFS 5.7 - Glibc configure doesn't have proper CC var as defined in 5.2

davecan · 11-28-2019, 01:13 PM

In section 5.2 there is a comment regarding section 5.7 (Glibc): (emphasis mine)

Quote:

After the run of configure, check the contents of the config.make file in the glibc-build directory for all important details. Note the use of CC="i686-lfs-gnu-gcc" to control which binary tools are used and the use of the -nostdinc and -isystem flags to control the compiler's include search path. These items highlight an important aspect of the Glibc package—it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults.

Now that I'm at section 5.7 I take a look at my /mnt/lfs/sources/glibc-2.30/build/config.make file as the instructions above advise, here is the relevant excerpt:

Code:

# Build tools.
CC = gcc
CXX = g++
BUILD_CC = gcc

My config.make file has a different CC setting than what the book says it should have in 5.2. Since this bit in 5.2 is stressed ("take no risks" etc) I'm wondering if there is something glossed over in the instructions. I ran the ../configure script exactly as shown in 5.7, from the /mnt/lfs/sources/glibc-2.30/build directory as directed.

Checking ../configure --help there is a statement that CC is an environment variable. But I don't recall a step where CC was set as an env var and it is definitely not set in my shell.

Do I need to do the following to move forward:

set CC=i686-lfs-linux-gnu-gcc
rm -rf $LFS/sources/glibc-2.30
unpack glibc and restart 5.7

Not sure if I would also need to remove anything from $LFS/tools.

Or can I ignore this and press forward? I saw another thread today where someone said they made it much farther simply pasting in the commands provided in the book, but they also ran into some issues later on, so I want to make sure I get mine correct.

Thanks.

Luridis · 11-29-2019, 02:07 AM

CC & CXX are env vars used on unix-like machines to tell the build system what compilers to use at build time. They usually point to GCC/G++, though they can point to Clang or icc (Intel's compiler), etc. If you look at BLFS and other things like Arch Linux package builds, you'll occasionally see a package that does this:

CC=clang CXX=clang ./configure --prefix=/usr --disable-static --sysconfdir=/etc

Those are usually the cases where it builds better with llvm/clang, or sometimes one or the other is specified because it doesn't build at all with the other. If they vars are empty, most packages will go ahead and look for GCC on a Linux system. You absolutely need GCC to build LFS as the kernel currently doesn't build with anything else without major patching.

davecan · 11-29-2019, 08:18 AM

Thanks Luridis. My specific question though is whether I can leave it as it is currently set in the configure script:

Code:

CC=gcc

Or if I should change it to

Code:

CC=i686-lfs-linux-gnu-gcc

-- which section 5.2 states the configure script should already contain but it does not.

5.2 rather emphatically states that it is important to get this correct now else problems will happen later, so I want to avoid that.

Also I'm assuming i686-lfs-linux-gnu-gcc is auto-generated somehow but there is nothing in my instance of uname that says "i686" so I'm not sure where that came from.

I'm wondering if the guidance in 5.2 is mistaken, or is the result of someone copypasting from their environment in an attempt to provide guidance, or perhaps it was required previously but is not outdated?

Luridis · 11-29-2019, 10:53 AM

What are you compiling on? 64 or 32 bits?

Also, if you've gotten as far as section 5.5, you will see either i686-lfs-linux-gnu-gcc or x86_64-lfs-linux-gnu-gcc as this cross compiler target name is created by this line in your lfs user's .bashrc

Code:

LFS_TGT=$(uname -m)-lfs-linux-gnu

Which then goes into the ./configure line in section 5.5. Before that, it should be calling on your host system's GCC. After GCC pass 1 it should be what is in $LFS_TGT. If it is not, erase everything in tools and start over. Before you start building, after you've su - lfs, do this:

Code:

source ~/.bashrc

Then echo $LFS $LFS_TGT $LC_ALL $PATH and make sure they're correct. It will look something like:

Code:

/mnt/lfs x86_64-lfs-linux-gnu POSIX /tools/bin:/bin:/usr/bin

davecan · 11-29-2019, 11:45 AM

This is a 64-bit system. Host is an Ubuntu 18.04 VM.

Quote:

you will see either i686-lfs-linux-gnu-gcc or x86_64-lfs-linux-gnu-gcc

See where?

lfs user .bashrc is in place and is properly sourced:

Code:

lfs@lfs-host-bionic:/mnt/lfs/sources/glibc-2.30$ echo $LFS $LFS_TGT $LC_ALL $PATH
/mnt/lfs x86_64-lfs-linux-gnu POSIX /tools/bin:/bin:/usr/bin

Quote:

If it is not ...

I completed 5.5 but deleted the GCC sources dir per the instructions in 5.3 which state to delete the sources dir after each compile unless otherwise directed, so I can't go back and verify the change you mention is in place in the GCC source configure file. I can wipe tools and go back to 5.4 and start over if needed though.

Also how do you get your `echo` statement to appear inline? I tried a variety of BBCodes I found online including inline, pre, tt etc but none worked.

davecan · 11-29-2019, 01:02 PM

Note also that per the statement from 5.2, running the ../configure script for Glibc should modify the config.make file, but in my case it did not.

I just wiped my Glibc source, re-extracted the tar and then followed 5.7 exactly.

I re-ran the Glibc ../configure script exactly as given in 5.7: (copypasted it into the shell)

Code:

../configure                             \
      --prefix=/tools                    \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --enable-kernel=3.2                \
      --with-headers=/tools/include

It produced this output:

Code:

lfs@lfs-host-bionic:/mnt/lfs/sources/glibc-2.30/build$ cat configure-output.txt
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-lfs-linux-gnu
checking for x86_64-lfs-linux-gnu-gcc... no
checking for gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc... gcc
checking for x86_64-lfs-linux-gnu-readelf... x86_64-lfs-linux-gnu-readelf
checking for x86_64-lfs-linux-gnu-g++... no
checking for x86_64-lfs-linux-gnu-c++... no
checking for x86_64-lfs-linux-gnu-gpp... no
checking for x86_64-lfs-linux-gnu-aCC... no
checking for x86_64-lfs-linux-gnu-CC... no
checking for x86_64-lfs-linux-gnu-cxx... no
checking for x86_64-lfs-linux-gnu-cc++... no
checking for x86_64-lfs-linux-gnu-cl.exe... no
checking for x86_64-lfs-linux-gnu-FCC... no
checking for x86_64-lfs-linux-gnu-KCC... no
checking for x86_64-lfs-linux-gnu-RCC... no
checking for x86_64-lfs-linux-gnu-xlC_r... no
checking for x86_64-lfs-linux-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ can link programs... yes
checking for sysdeps preconfigure fragments... aarch64 alpha arm csky hppa i386 m68k microblaze mips nios2 powerpc riscv s390 sh sparc x86_64 checking whether gcc compiles in -mx32 mode by default... no

checking for use of fpu sysdeps directories... yes
checking for -fstack-protector... yes
checking for -fstack-protector-strong... yes
checking for -fstack-protector-all... yes
checking for assembler and linker STT_GNU_IFUNC support... yes
checking for gcc attribute ifunc support... yes
checking whether the linker supports textrels along with ifunc... yes
checking if compiler warns about alias for function with incompatible types... no
checking sysdep dirs... sysdeps/unix/sysv/linux/x86_64/64 sysdeps/unix/sysv/linux/x86_64 sysdeps/unix/sysv/linux/x86 sysdeps/x86/nptl sysdeps/unix/sysv/linux/wordsize-64 sysdeps/x86_64/nptl sysdeps/unix/sysv/linux sysdeps/nptl sysdeps/pthread sysdeps/gnu sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/x86_64 sysdeps/unix sysdeps/posix sysdeps/x86_64/64 sysdeps/x86_64/fpu/multiarch sysdeps/x86_64/fpu sysdeps/x86/fpu sysdeps/x86_64/multiarch sysdeps/x86_64 sysdeps/x86 sysdeps/ieee754/float128 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64/wordsize-64 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/wordsize-64 sysdeps/ieee754 sysdeps/generic
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether as is GNU as... yes
checking whether ld is GNU ld... yes
checking for as... as
checking version of as... 2.30, ok
checking for ld... ld
checking version of ld... 2.30, ok
checking for gnumake... no
checking for gmake... no
checking for make... make
checking version of make... 4.1, ok
checking for gnumsgfmt... no
checking for gmsgfmt... no
checking for msgfmt... no
checking for makeinfo... makeinfo
checking version of makeinfo... 6.5, ok
checking for sed... sed
checking version of sed... 4.4, ok
checking for gawk... gawk
checking version of gawk... 4.1.4, ok
checking for bison... bison
checking version of bison... 3.0.4, ok
checking if gcc is sufficient to build libc... yes
checking for x86_64-lfs-linux-gnu-nm... x86_64-lfs-linux-gnu-nm
checking for python3... python3
checking version of python3... 3.6.9, ok
checking LD_LIBRARY_PATH variable... ok
checking for bash... /bin/bash
checking for perl... /usr/bin/perl
checking for install-info... /usr/bin/install-info
checking for .set assembler directive... yes
checking linker support for protected data symbol... yes
checking linker support for INSERT in linker script... yes
checking for broken __attribute__((alias()))... no
checking whether to put _rtld_local into .sdata section... no
checking whether to use .ctors/.dtors header and trailer... no
checking for libunwind-support in compiler... no
checking whether --noexecstack is desirable for .S files... yes
checking for -z combreloc... yes
checking for linker that supports -z execstack... yes
checking for linker that supports --no-dynamic-linker... yes
checking for -static-pie... no
checking for -fpie... yes
checking for --hash-style option... yes
checking for sufficient default -shared layout... no
checking for GLOB_DAT reloc... yes
checking linker output format... elf64-x86-64
checking for -fno-toplevel-reorder -fno-section-anchors... yes
checking for -mtls-dialect=gnu2... yes
checking whether cc puts quotes around section names... no
checking for __builtin_memset... yes
checking for redirection of built-in functions... yes
checking for compiler option to disable generation of FMA instructions... -ffp-contract=off
checking if gcc accepts -fno-tree-loop-distribute-patterns with __attribute__ ((__optimize__))... yes
checking for libgd... no
checking for is_selinux_enabled in -lselinux... no
checking for _FORTIFY_SOURCE predefine... yes
checking whether the linker provides working __ehdr_start... yes
checking for __builtin_trap with no external dependencies... yes
checking whether the C++ compiler supports thread_local... yes
running configure fragment for sysdeps/unix/sysv/linux/x86_64/64
running configure fragment for sysdeps/unix/sysv/linux/x86_64
running configure fragment for sysdeps/unix/sysv/linux
checking installed Linux kernel header files... 3.2.0 or later
checking for kernel header at least 3.2... ok
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/x86_64
checking for AVX512DQ support in assembler... yes
checking for AVX512 support... yes
checking -mprefer-vector-width=128... no
checking for Intel MPX support... yes
running configure fragment for sysdeps/x86
checking whether -fPIC is default... yes
checking whether -fPIE is default... yes
configure: creating ./config.status
config.status: creating config.make
config.status: creating Makefile
config.status: creating config.h
config.status: executing default commands

After that, per the guidance in section 5.2 I then checked my Glibc config.make again:

Code:

lfs@lfs-host-bionic:/mnt/lfs/sources/glibc-2.30/build$ grep CC config.make
CC = gcc
BUILD_CC = gcc
AS = $(CC) -c

As you can see, even though I followed the instructions as given in 5.7 my config.make file does not appear correct.

So really what I'm asking is, do I need to manually modify the config.make file (and if so, why? what happened?) or can I press forward with its current CC=gcc value and proceed forward? (I'm assuming I need to manually modify the file but want to be sure before I proceed)

Thanks.

Luridis · 11-29-2019, 01:51 PM

I'll have to do that section myself and look, meanwhile post the results of printenv as the lfs user.

davecan · 11-29-2019, 02:48 PM

Thanks. Here's the printenv:

Code:

lfs@lfs-host-bionic:/mnt/lfs/sources/glibc-2.30/build$ printenv
LC_ALL=POSIX
OLDPWD=/mnt/lfs/sources/glibc-2.30
LFS=/mnt/lfs
PWD=/mnt/lfs/sources/glibc-2.30/build
HOME=/home/lfs
LFS_TGT=x86_64-lfs-linux-gnu
TERM=xterm-256color
SHLVL=1
PATH=/tools/bin:/bin:/usr/bin
PS1=${debian_chroot:+($debian_chroot)}\u@\h:\w\$
_=/usr/bin/printenv

Luridis · 11-29-2019, 03:54 PM

I think I know what's going on now, but I'm double checking it now. I haven't done Chapter 5 in a while because I have a tarred up /tools that saves a couple hours. Anyway, I think you're confusing the output of config.guess with the contents of config.make. And, right now, before I even look CC=GCC is what I would assume is correct.

davecan · 11-29-2019, 04:09 PM

Hmm. I'm looking at this section further down in 5.2, not the yellow note about config.make higher up.

This is the 4th para from the bottom of 5.2. Note I'm version 9.0, here's the link direct to the section: http://www.linuxfromscratch.org/lfs/...technotes.html

I'll bold the sentences I'm focusing on.

Quote:

The next package installed is Glibc. The most important considerations for building Glibc are the compiler, binary tools, and kernel headers. The compiler is generally not an issue since Glibc will always use the compiler relating to the --host parameter passed to its configure script; e.g. in our case, the compiler will be i686-lfs-linux-gnu-gcc. The binary tools and kernel headers can be a bit more complicated. Therefore, take no risks and use the available configure switches to enforce the correct selections. After the run of configure, check the contents of the config.make file in the glibc-build directory for all important details. Note the use of CC="i686-lfs-gnu-gcc" to control which binary tools are used and the use of the -nostdinc and -isystem flags to control the compiler's include search path. These items highlight an important aspect of the Glibc package—it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults.

It states (3rd sentence) that Glibc will use the --host param from the configure script, and based on the wording (3rd sentence and 6-7 sentence) I take that to mean the config.make is supposed to be updated with the contents of the --host param, but it isn't.

I could be misunderstanding something there though, I don't compile code on these platforms so this is new.

Luridis · 11-29-2019, 04:20 PM

On a Core i5 Asus laptop running Manjaro Mate, section 5.2 config.guess run...

Code:

x86_64-pc-linux-gnu

After 5.5, config.guess returns:

Code:

x86_64-pc-linux-gnu

And the result of grepping CC from config.make:

Code:

grep CC config.make 
CC = x86_64-lfs-linux-gnu-gcc
BUILD_CC = gcc
AS = $(CC) -c

So yes, it's not seeing the cross compiler. The cross compiler is necessary to disconnect the programs in /tools from the host's toolchain. Somehow, Glibc's configure script is ignoring what's stated in the configure line "--host=$LFS_TGT" and still hooking onto the build host's GCC. You could try running configure like this:

Code:

CC=x86_64-lfs-linux-gnu-gcc \
../configure                             \
      --prefix=/tools                    \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --enable-kernel=3.2                \
      --with-headers=/tools/include

But, that doesn't mean something else won't bleed through from the host later. For example, when you tell the Make package's configure to ignore any installed version of Guile.

All of this is probably why many experienced LFS builders, including me, recommend not using Debian hosts to build LFS. I haven't successfully started a build on Debian in at least a decade. They always seem to bleed something over from the host's build environment. As for what I use: Arch, Manjaro & Slackware have all worked fine for me. If you're comfortable working exclusively in the terminal, Arch can do it with just a couple of meta packages installed: base & base-devel along with linux, grub, sudo, linux-firmware and maybe lynx, vim, & gpm if you're not running from a GUI.

davecan · 11-29-2019, 04:55 PM

Thank you very much for the time. I'm working solely from the command line now and I don't have any issue switching to Arch. So I'll give that a try.

My whole purpose for doing this project is to finally *actually* learn Linux at a deeper level instead of googling commands when I use Linux once a year or even less. Instead of following a tutorial that just teaches commands I want to learn how it is engineered and works internally first and build up from there, to establish a foundation on which I can build as I move deeper into security. Since the purpose is to learn not to build a system for use then working in a VM is ideal, and I arbitrarily picked Ubuntu since it is popular.

All that is said to say I'm comfortable putting in the work, but when I run into issues like this I don't know what to do, so I have to reach out for help here. And I really appreciate the time you put in to get me onto a better track.

I'm sure I'll ask more questions as I go but I'll try to get back to at least this point on my own with Arch first.

Luridis · 11-29-2019, 11:05 PM

Here is what you'll need, in order, for a pretty complete development BLFS console system. Just about any serious use of the system will need these things installed. Note that there's a lot I'm not putting here, like my LFS customizations, custom patches, seds an configure lines.

Legend for my notations, even though many need updating at this point.
package* - Missing optional dependencies, usually desired.
+package - Optional package rebuild, usually to pick up desired dependencies.
[package] - Pretty necessary rebuild, do to security functions. (Linux-PAM)

Code:

LFS EFI Addions: (skip Book GRUB), re2c (before Ninja),
popt, efivar, efibootmgr, dosfstools (if ESP not present), GRUB2

After kernel, before exiting chroot: gpm, lynx*, openresolv, dhcpcd
::

sudo*, wget*, unzip, sqlite, nspr, nss, libtasn1, p11-kit, make-ca, COA, bash-completion
:: (Create LFS base backup.)

which, tcl, expect, dejagnu, check, pth, icu, libunistring, berkeley-db,
zip, libgpg-error, libgcrypt, python2*, +python3*, autoconf-2.13, sphinx,
libxml2, libxslt, asciidoc, sgml-common, docbook-xml, docbook-xsl, xmlto,
yasm, nasm
::

unixODBC, libldap, krb5, libtirpc, libnsl, libyaml, jansson, json-c,
jsoncpp, pcre, pcre2, +grep, glib, GOI, json-glib, boost, npth, libcroco,
libuv, libpng, lzo, lz4, libidn, libidn2, c-ares, ldns, libpsl, libssh2,
libevent, libnghttp2, libseccomp, +file, lxml, libusb, libassuan, libksba,
nettle, gnutls, curl*, libarchive, xapian
::

gcc-go, gfortran, gdc, cmake*, recommonmark, llvm, compiler-rt, clang, rustc,
cython, slang, lua, swig, mozjs, itstool, gtk-doc*, git, doxygen*, pin-entry*,
gnupg*, gpgme*, +wget, +lynx
::

lmsensors, linux-pam, [libcap], libcap-ng, fcron, pciutils, usbutils,
fuse3, ntfs3g, gptfdisk, dosfstools, parted, rsync, [shadow], [systemd]*,
[dbus]*, [sudo], polkit, +kbd, +util-linux
::

hunspell, aspell, enchant, cpio, p7zip, time, lsof, tree, nano, htop, mc
:: (Create LFS console backup.)

---Console-Complete---

<sniped from my Mate Desktop build log>

That will give you pretty close to what Arch has with base & base-devel, or the Gentoo Stage 3.

davecan · 11-30-2019, 10:18 AM

Quick question Luridis:

The host I'm using now is an Arch 2019.05 VM prebuilt from osboxes.org: https://www.osboxes.org/arch-linux/

When I installed base-devel it installed Binutils 2.33.1.

Section 2.2 states "Versions greater than 2.32 are not recommended as they have not been tested."

Since you have experience building LFS on Arch, do I need to go through the process of downgrading Binutils to 2.32? (which may involve downgrading dependencies, I'm still researching from the Arch downgrade instructions)

If not I'll press on but want to be sure before I do. Thanks.

Edit: Checking the version history I see Binutils went from 2.32 to 2.33.1. Checking the release notes there were only new features added, no breaking changes reported.

https://ftp.gnu.org/gnu/binutils/

https://lists.gnu.org/archive/html/i.../msg00006.html

Given that I'm going to press forward with 2.33.1 but I'll check back here periodically to see if you have any warnings against this, and if so I'll rewind to 2.2 and downgrade as needed.