[lfs-dev] static libs: libc_nonshared.a and also gcc tests

William Harrington kb0iic at berzerkula.org
Sat Mar 14 19:56:16 PDT 2015

On Sat, 14 Mar 2015 15:18:45 +0000
Ken Moffat <zarniwhoop at ntlworld.com> wrote:

> Posting this under a slightly different title, to start a separate
> thread.
> 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

Hello Ken,

I've been watching this thread for the last few days. There is the conclusion that there are a minimal set of static libs which need to be installed for a successful build and an expanded set for testsuites.

Anyone running test suites wouldn't be stripping the system in any way.

I've ran many builds with the minimal static libs. I moved all static libs to a temp directory and I moved the static libs which were needed.

I see that the controversial one is libc_nonshared.a.  This library is required no matter what. Let me explain why:

# What we install as libc.so for programs to link against is in fact a
# link script.  It contains references for the various libraries we need.
# The libc.so object is not complete since some functions are only defined
# in libc_nonshared.a.
# We need to use absolute paths since otherwise local copies (if they exist)
# of the files are taken by the linker.

That is in one of the Makefiles of GLIBC.

Do not remove libc_nonshared.a in any situation. It is also not able to build a static binary without it (if I recall properly).

If a user wants to build a static binary in the future, they will not have the static libraries at all. I would suggest we let the user decide if they want to install the static libs or not. All of this --disable-static options and removing static libs should not be an issue with an LFS build. The user needs to decide if they want to install them or not.

More time is being spent removing static libs than what the outcome is worth.


William Harrington

More information about the lfs-dev mailing list