Re: Revert "package bbclass: strip static libs as well"

[Stanislav Brabec <utx@penguin.cz>]

Phil Blundell wrote:
> On Sat, 2009-10-24 at 10:48 +0200, Koen Kooi wrote:
> > On 24-10-09 00:31, Stanislav Brabec wrote:

> > > binutils-2.18-r8.1: /usr/lib/libiberty.a
> 
> I'm not convinced you really want to be shipping libiberty at all.
> Every project that uses this library tends to bundle a local copy in
> with its source code.

Probaby agree. One instance of libibery per distro with header still
can exist.

> > > bison-2.3-r0: /usr/lib/liby.a
> 
> That one is a special case: it wants to stay in the main bison
> package,
> since bison itself is a development tool.  I'm not sure why it is a
> static-only library; that might be an error.

It's OK. Ultra small shared libraries with one or two functions don't
make sense.

> > > bridge-utils-1.4-r0: /usr/lib/libbridge.a
> 
> I think this is an internal convenience library, not intended for
> external use.  Debian doesn't seem to package it at all and I suspect
> OE
> probably shouldn't either.

There shoud be another generic rule: No .h files for the library =>
don't package the library.

libbridge.h is available => it's OK to have libbridge. I cannot
decide whether it is useful without a knowledge of the package.

> > > flex-2.5.31-r4: /usr/lib/libfl.a
> 
> This is like bison.

Yes, again an ultra small library.
 
> > > gcc-4.3.3-r7.1: /usr/lib/libstdc++_pic.a
> > > gcc-4.3.3-r7.1: /usr/lib/libssp_nonshared.a
> 
> Those are probably special.  I'm not quite sure what the deal is with
> libstdc++_pic, that would need some further investigation.

_pic.a is a convenient name for static libraries, if their contents may
be linked into a shared library (i. e. they are compiled with -fPIC).
 
> > > gdb-7.0-r0: /usr/lib/libbfd.a
> > > gdb-7.0-r0: /usr/lib/libopcodes.a
> > > gdb-7.0-r0: /usr/lib/libiberty.a
> 
> As for libiberty above.

Yes.

> > > glibc-2.9-r35.2: /usr/lib/libc_nonshared.a
> > > glibc-2.9-r35.2: /usr/lib/libmcheck.a
> > > glibc-2.9-r35.2: /usr/lib/libg.a
> > > glibc-2.9-r35.2: /usr/lib/libbsd-compat.a
> > > glibc-2.9-r35.2: /usr/lib/libieee.a
> > > glibc-2.9-r35.2: /usr/lib/libpthread_nonshared.a
> 
> The nonshared ones are special.  The others belong in the -static
> package.

No for libpthread_nonshared.a. pthread_atfork is defined only here.

No for libmcheck.a. It is required for -mcheck*.

I am not sure for others. Some of them are dummy, but compiler may want
it. I guess we are on the safe side keeping all these in the main
package.

> > > mysql-4.1.22-r3: /usr/lib/libmysys.a
> > > mysql-4.1.22-r3: /usr/lib/libdbug.a
> > > mysql-4.1.22-r3: /usr/lib/libvio.a
> > > mysql-4.1.22-r3: /usr/lib/libheap.a
> > > mysql-4.1.22-r3: /usr/lib/libmerge.a
> > > mysql-4.1.22-r3: /usr/lib/libnisam.a
> > > mysql-4.1.22-r3: /usr/lib/libmysqld.a
> > > mysql-4.1.22-r3: /usr/lib/libmyisam.a
> > > mysql-4.1.22-r3: /usr/lib/libmyisammrg.a
> > > mysql-4.1.22-r3: /usr/lib/libmystrings.a
> 
> I think those are all internal convenience libraries and should
> probably
> not be packaged.

I don't know mysql in deep. But if it has correspondent headers
installed, somebody may consider it useful.


But There are many really obsolete .a files:

All libraries intended for load by ltdl, gmodule etc.

Static instances of dynamic modules have absolutely no use and may be 
silently deleted in the recipe.

It includes: GTK+ theme engines, input methods, pixbuf renderers and
a lot of other stuff.

Upstream does not do so, because libtool is not so flexible to create
static libraries only for part of the package.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx