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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
