[lfs-dev] More on static libs

Fernando de Oliveira famobr at yahoo.com.br
Fri Mar 13 06:46:39 PDT 2015


On 13-03-2015 00:58, Bruce Dubbs wrote:
> Douglas R. Reno wrote:
>> On Thu, Mar 12, 2015 at 9:36 PM, Bruce Dubbs <bruce.dubbs at gmail.com>
>> wrote:
> 
>> I have followed that some distributions have
>> them and some don't, but I understand that the real question is
>> whether or
>> not we need them.

That's true, but difficult to cover everything, unless we start using
systems with them removed. At the moment, my new host and dev system to
be has them removed, after gcc (IIRC).

> Under certain circumstances, static libraries can cause problems, so we
> probably do want to minimize them.  Generally if there is a libsample.a
> and a libsample.so, the linker will select the .so version, but if it
> doesn't exist, it will us the .a version.  If there is  a bug in
> libsample, replacing the libraries isn't enough with the static library;
> you have to relink all executables that use that library -- and often
> you don't knwo which ones they are.

Yes.

> I though ubuntu didn't include the .a files at first, but then found
> them in
> usr/lib/x86_64-linux-gnu/ or /usr/lib/gcc/x86_64-linux-gnu/`gcc --version`.
> 
> Looking at Linux Mint, I do notice that I cannot find libc_nonshared.a,
> but it may not have all the -devel packages installed.  It does have
> libc-2.19.so which is a real library and not just link instructions like
> a standard glibc build uses.

I think that a freshly installed distribution might not have all the *.a
it could after some use. In this system below described, I have compiled
two at least packages, porg and seamonkey, which needed some dev
installs. And also need many others were necessary for the LFS7.7 build.
So, I do have libc_nonshared.a:

$ uname -a
Linux MintMate 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
$ find /usr/lib/ /lib/ -name libc_nonshared.\*
/usr/lib/x86_64-linux-gnu/libc_nonshared.a

But I would much prefer to disable as much as we could by configure or
makefile choices, only moving out the others, after compressing. Move,
then compress wouldn't work in an upgrade. Mus be compress, then move.

Of course, as stated above and in other posts, I believe that gcc and at
least and glibc should be left alone, but cannot prove I'm correct.

For binutils, just analised, and we have:

/usr/lib/libbfd-2.25.so
/usr/lib/libbfd.a
/usr/lib/libbfd.so
/usr/lib/libopcodes-2.25.so
/usr/lib/libopcodes.a
/usr/lib/libopcodes.so

I will compress and move out /usr/lib/libbfd.a and
/usr/lib/libopcodes.a, have a feeling they are not needed.

-- 
[]s,
Fernando


More information about the lfs-dev mailing list