[lfs-dev] static libs: libc_nonshared.a and also gcc tests
bruce.dubbs at gmail.com
Sat Mar 14 09:12:20 PDT 2015
Ken Moffat wrote:
> Posting this under a slightly different title, to start a separate
> 1. For libc_nonshared.a I have concluded that it is not worth the
> testing effort to keep it out of the normal search path. In other
> words. I keep it at /usr/lib/libc_nonshared.a : as well as the
> book's sanity test, I had failures in linking the static libz.a, and
> then I got "C compiler cannot create executables" in one of the
> next configure scripts. For me, in the light of what Bruce pointed
> out about current libc.so being an ld script, I have concluded that
> it will be a waste of time, and fragile, to find exactly which
> packages/tests need this.
> 2. With that file available, my i686 gcc/g++ tests had failures in
> pr59063-2.c (gcc,g++) and pr61160-3.c (g++). On a completed system,
> copying the tests and linking with -L, -Wl,--verbose just works (the
> shared libs are found), but creating static executables seems to
> need libc.a for gcc, and libstdc++.a and libm.a for g++. At the
> moment, this is untested - I will start a build shortly, and pick up
> what Bruce reported for the binutils tests.
> This time, even if some of these tests still fail I intend to move
> on an build a bootable qemu system, followed by some of BLFS (all
> with 7.7 versions) to get a feel for how much pain hiding static
> parts of libc might cause (but I won't run tests in BLFS).
Figuring this out is good knowledge, but many of our users do run tests in BLFS.
Personally, I run tests when doing an upgrade for the book and assume that
other editors also do that. When doing a check, like during the package freeze
before release where I'm building most of the packages in the book, I do not
generally run the tests.
My impression is that most of the issues where tests want to use static
libraries actually are in the tests run by the basic packages of LFS, especially
binutils and gcc. Packages in BLFS Chapter 13 are also candidates. However we
really won't know for sure until each package is tested.
In any case, I don't want to complicate LFS/BLFS by doing a lot of moving
packages or specifying -L /usr/lib/some-special-dir-with-static-libraries more
than a very few times. I can see it for libz.a, but not for important gcc or
glibc static libs.
More information about the lfs-dev