Opened 6 years ago

Closed 6 years ago

#3751 closed task (fixed)

Get rid of most of the static libraries

Reported by: Armin Owned by: lfs-book@…
Priority: normal Milestone: 7.8
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

In BLFS, we disable almost all static libraries in packages that can be made to do so, mostly for security reasons. We should probably do the same with all the packages in LFS, but the Glibc and GCC itself and possibly move the "Libraries: Static or Shared" page from BLFS.

Postponing to 7.8.

Change History (11)

comment:1 by bdubbs@…, 6 years ago

I took a look at this. We have a total of 79 static libraries right now. All but three from gcc are in /usr/lib.

gcc has 3 in /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2 and 14 in /usr/lib. glibc has 17 static libraries, ncurses 12, util-linux 5, e2fsprogs 4, and the rest 1 or 2.

7 of the libcurses libraries are symbolic links.

I wonder if just doing 'rm /usr/lib/*a' would work, but I don't know if any of those static libraries are really necessary or not. That would certainly be easier than changing 23 packages to add --disable-static. It would also get rid of the 43 .la files that we don't need.

Opinions?

comment:2 by Armin, 6 years ago

That's a bad idea. Some libraries are static only, such as Bison liby.a. You can't also go and remove Flex libfl.a as libfl.so seems to be sort of broken and we override automake to use the static one. And even if the last two cases weren't needed, you'd also remove libstdc++.a and libc.a which we really don't want to do as we would prevent people from being able to statically link their C/C++ programs.

I can see what it needs to be done if you like.

comment:3 by bdubbs@…, 6 years ago

I suspected something like that. You are more familiar with what's needed in this area than I am, so please tell me what we need.

comment:4 by ken@…, 6 years ago

s well as liblf.a, I make libz.a visible while testing binutils - I've been doing that since the end of January 2014 (man, recent versions of git are so sloooow, that took ages to find when I did it). Before that, some of the tests, I think for ld, failed - details are probably in the list archives. Might not still be needed, I have no idea. From LFS, all my other non-toolchain static libs in /usr/lib are renamed (I'm reluctant to delete things which might turn out to be required later), but I never touch most of the toolchain, or the /usr/lib/gcc/$ARCH variants.

For the toolchain, I do hide a few old static libs, the current list of those I keep visible is libc.a, libc_nonshared.a, libdl.a, libg.a, libieee.a, libm.a, libpthread_nonshared.a, librpcsvc.a, libsupc++.a.

Or, to put it another way, I can build the system by making the following unavailable: libBrokenLocale.a, libanl.a, libcrypt.a, libmcheck.a, libnsl.a, libpthread.a, libresolv.a, librt.a, libutils.a.

But I wish I had thought about this earlier - since I last checked for static libs, a lot has changed and I now have a shed load of them (renamed, of course) in this current part-completed BLFS system.

in reply to:  4 comment:5 by ken@…, 6 years ago

Replying to ken@…:

s well as liblf.a, I make libz.a visible while testing binutils - I've been doing that since

Sorry, that should be "As well as libfl.a..." - the ticket changed under me, I copied but missed the first character.

comment:6 by Armin, 6 years ago

I'm looking at Archlinux and they seem to be keeping the following libs from glibc:

libc.a
libc_nonshared.a
libcrypt.a
libdl.a
libg.a
libieee.a
libm.a
libmcheck.a
libpthread.a
libpthread_nonshared.a
librpcsvc.a

All of them make sense as some are static only and others are mostly wanted by people building static programs (pthread, math, libc, dl, crypt).

That leaves only the following ones to remove:

libanl.a
libBrokenLocale.a
libnsl.a
libresolv.a
librt.a
libutil.a

Which is what they did. I don't however think it's worth the effort, so lets just leave glibc as it is. Also, thanks for the hint about zlib library.

comment:7 by ken@…, 6 years ago

I've started looking at the static libs I got from my build (some were alread suppressed), the first one (alphabetically) is acl and I had been passing --disable-static without noticing htat did not have any effect. What a pain this package is - does not really respect DESTDIR (partially installs to /tmp/somedir if that is created first, but no libs), otherwise passing a DESTDIR seems to casuie it to run through every directory but do nothing. Then I tried using a prefix I can write to, and it failed trying to chmod bin, before any libs were installed.

comment:8 by bdubbs@…, 6 years ago

I've got a pretty fast machine. If I use all processors and skip all tests, I can do a full lfs build in about an hour. jhalfs can give a list of files installed so that would be easy enough to see what happened.

Thhe downside of course is having to do it for a lot of packages. If we can do DESTDIR, that that would be a lot more efficient.

I'll do acl now and and we cna go from there.

in reply to:  8 comment:9 by ken@…, 6 years ago

Replying to bdubbs@…:

I'll do acl now and and we cna go from there.

Thanks, I am beginning to doubt my sanity now - just let root install acl to /opt/ACL and with --disable-static there was no static lib. But in my real build it put libacl.a into /usr/libexec (!)

/tools/bin/make -C libacl install-dev
make[1]: Entering directory '/building/acl-2.2.52/libacl'
cd ../libacl/.libs; 
../../include/install-sh -o root -g root -m 755 -d /usr/libexec; 
../../include/install-sh -o root -g root -m 644 -T old_lib libacl.lai /usr/libexec;
../../include/install-sh -o root -g root -m 644 libacl.lai /usr/libexec/libacl.la ;
../../include/install-sh -o root -g root -m 755 -d /usr/lib; 
../../include/install-sh -o root -g root -T so_base libacl.lai /usr/lib; 

if test "x/usr/libexec" != "x/usr/lib" ; then 
  ../../include/install-sh -o root -g root -S /usr/libexec/libacl.a /usr/lib/libacl.a; 
  ../../include/install-sh -o root -g root -S /usr/libexec/libacl.la /usr/lib/libacl.la; 
  ../../include/install-sh -o root -g root -S /usr/lib/libacl.so /usr/libexec/libacl.so;
fi
cp: missing destination file operand after '//usr/libexec/'
Try 'cp --help' for more information.
make[1]: Leaving directory '/building/acl-2.2.52/libacl'
Last edited 6 years ago by bdubbs@… (previous) (diff)

comment:10 by bdubbs@…, 6 years ago

Ok, here is what I got excluding /usr/share:

/bin/chacl      33744   root:root       755
/bin/getfacl    74944   root:root       755
/bin/setfacl    107776  root:root       755
/lib/libacl.so.1        15      root:root       777     libacl.so.1.1.0
/lib/libacl.so.1.1.0    186544  root:root       755
/usr/include/acl/libacl.h       2590    root:root       644
/usr/include/sys/acl.h  3755    root:root       644
/usr/lib/libacl.la      916     root:root       644
/usr/lib/libacl.so      21      root:root       777     ../../lib/libacl.so.1

Looks OK to me.

comment:11 by bdubbs@…, 6 years ago

Resolution: fixed
Status: newclosed

Removed non-essential static libraries from the installation. Added a new section in Chapter 6 Introduction, suppressed many static libraries in different packages, and removed the remaining in the Cleaning Up section.

Fixed at revision 10880.

Note: See TracTickets for help on using tickets.