LFS 11.3 x86_64 zlib warning in binutils configure phase

jr_bob_dobbs · 04-24-2023, 04:54 PM

I'm currently in the middle of a LFS build. I'm following the LFS 11.3 book on my x86_64 computer, except for six deviations.

One. As I did in my previous LFS 8.0, 8.1 and 11.2 installs, I am using the Slackware package tools as the package manager for my LFS. This is verified stable technology that I've used before. For LFS 11.2 on, a newer version of the tools was used, with the advantage of not needing a special version of tar as previous versions did. The Slackware package manager is briefly mentioned in Section 8.2.2.7, paragraph four of the LFS 11.3 book. Naturally this means the packages will not be compiled in the $LFS/sources directory but in a different directory tree, in which each package is compiled and packed in its own directory, while the package contents are installed to the usual locations.

Two. The "which" command is a dependency of one of the Slackware tools. I installed the shell script version from the BLFS book, along with the Slackware tools, before the first package of Chapter 8.

Three. This LFS build, as was done in previous successful builds, is being done in multiple sessions. $LFS is defined for all required users and scripting was created for mistake-free chrooting. The LFS volume is in /etc/fstab and is mounted at boot time.

Four. I'll be installing my text editor instead of vim.

Five. Before the system is bootable, cryptsetup, cpio and lvm-related programs will need to be compiled, because all Linux distros on my computer reside on thin-provisioned LVM partitions.

Six. I'm using the 5.15.86 version of the kernel, because that worked so well with my hardware in my LFS 11.2 system.

A pause to quote from Chapter One of the LFS 11.3 book:

Quote:

Deviating from this book does not mean that we will not help you. After all, LFS is about personal preference. Being up-front about any changes to the established procedure helps us evaluate and determine possible causes of your problem.

Having performed due-diligence as to disclosure about my deviations from the "established procedure," of the LFS 11.3 book, I will now begin my actual question.

In chapter 8, specifically 8.18. "Binutils-2.40", when checking the configure log (my slack-build for this package logs the output of the configure phase) I found the following warning:

Code:

*** This configuration is not supported in the following subdirectories:
     zlib
    (Any other directories should still work fine.)

The tests for binutils yielded twelve errors:

Code:

./gold/testsuite/test-suite.log:FAIL: weak_undef_test
./gold/testsuite/test-suite.log:FAIL: initpri3a
./gold/testsuite/test-suite.log:FAIL: script_test_1
./gold/testsuite/test-suite.log:FAIL: script_test_2
./gold/testsuite/test-suite.log:FAIL: justsyms
./gold/testsuite/test-suite.log:FAIL: justsyms_exec
./gold/testsuite/test-suite.log:FAIL: binary_test
./gold/testsuite/test-suite.log:FAIL: script_test_3
./gold/testsuite/test-suite.log:FAIL: tls_phdrs_script_test
./gold/testsuite/test-suite.log:FAIL: script_test_12i
./gold/testsuite/test-suite.log:FAIL: incremental_test_2
./gold/testsuite/test-suite.log:FAIL: incremental_test_5

The book says: "Twelve tests fail in the gold test suite when the --enable-default-pie and --enable-default-ssp options are passed to GCC."
From the configure of Pass 2 of GCC in 6.18.1.:

Code:

../configure                                       \
    --build=$(../config.guess)                     \
    --host=$LFS_TGT                                \
    --target=$LFS_TGT                              \
    LDFLAGS_FOR_TARGET=-L$PWD/$LFS_TGT/libgcc      \
    --prefix=/usr                                  \
    --with-build-sysroot=$LFS                      \
    --enable-default-pie                           \
    --enable-default-ssp                           \
    --disable-nls                                  \
    --disable-multilib                             \
    --disable-libatomic                            \
    --disable-libgomp                              \
    --disable-libquadmath                          \
    --disable-libssp                               \
    --disable-libvtv                               \
    --enable-languages=c,c++

it is apparent that those options were passed to GCC.

Is that configure warning from binutils something I should be concerned about? To phrase my question another way: does this mean that the binutils configure phase did not use the existing already installed zlib?

Thank you.

hazel · 04-25-2023, 05:49 AM

From the way the warning is worded, I think these flags are a deviation from protocol that some people are expected to make out of necessity. In other words, the errors are expected failures, like the ones you often get with gcc. I don't know about the zlib thing.

jr_bob_dobbs · 04-25-2023, 10:59 AM

Quote:

Originally Posted by hazel

I don't know about the zlib thing.

That's the part that really is the concern.

In LFS 11.2, my script didn't log the configure, just the tests, so I can't compare the 11.3 configure log against it. So today, I de-tarred and ran a configure of binutils 2.39 from LFS 11.2 in my regular Linux. It produced the exact same warning message. Hmm!

I looked through my 11.3 Slackbuild script again, ensuring that yes it corresponds to the LFS 11.3 book. It does.

I'd be curious, if anyone else has had that zlib warning.

jr_bob_dobbs · 04-25-2023, 12:40 PM

I de-tarred the (not yet installed) binutils slack package to a temp directory. Used ldd to see what libraries the programs of binutils needed and got this result:

Code:

/lib64/ld-linux-x86-64.so.2
libbfd-2.40.so
libc.so.6
libctf-nobfd.so.0
libctf.so.0
libfl.so.2
libgcc_s.so.1
libgprofng.so.0
libm.so.6
libopcodes-2.40.so
libsframe.so.0
libstdc++.so.6
libz.so.1
linux-vdso.so.1

Hmm: libz sounds suggestive of a file that could be part of zlib. A nice thing about using a package manager is that I can find out what package a given file belongs to, so let's do that:

Code:

(lfs chroot) root:~# grep libz /var/lib/pkgtools/packages/*
/var/lib/pkgtools/packages/zlib-1.2.13-x86_64-1_lfs:usr/lib/libz.so.1.2.13
/var/lib/pkgtools/packages/zstd-1.5.4-x86_64-1_lfs:usr/lib/libzstd.so.1.5.4
/var/lib/pkgtools/packages/zstd-1.5.4-x86_64-1_lfs:usr/lib/pkgconfig/libzstd.pc
(lfs chroot) root:~#

This indicates that libz,so.1, referenced by at least one of the binaries of the binutils package, is part of the zlib package. Aha! So, despite the warning, the configure process of binutils did set things up to use the zlib library. Looks good. My confidence level is now high enough to installpkg binutils and continue work on this LFS.