Revert "package bbclass: strip static libs as well"

Revert "package bbclass: strip static libs as well"

[Holger Hans Peter Freyther]

Hey Koen, All,

I would like to revert:
	8fec15f70dcd0a8543b0af3ec256bf9cd108281e
	98a7d32826bc362c4ee434e7a4def7c852e75281

The reason is that:
	This commit has introduced several breakages including
	stripping libc_nonshared.a breaking the gcc in the SDK and
        for the device.
        It has created build errors in meta-toolchain for binutils, gdb
        see my illfated patch...

I don't think we need to strip .a files as they will not end on the device
and people will link their binaries to them and we will strip the binaries.

regards

	z.

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

[Koen Kooi]

On 23-10-09 05:04, Holger Hans Peter Freyther wrote:
> Hey Koen, All,
>
> I would like to revert:
> 	8fec15f70dcd0a8543b0af3ec256bf9cd108281e
> 	98a7d32826bc362c4ee434e7a4def7c852e75281
>
> The reason is that:
> 	This commit has introduced several breakages including
> 	stripping libc_nonshared.a breaking the gcc in the SDK and
>          for the device.
>          It has created build errors in meta-toolchain for binutils, gdb
>          see my illfated patch...
>
> I don't think we need to strip .a files as they will not end on the device

They do actually

> and people will link their binaries to them and we will strip the binaries.

There was a discussion about that and I didn't see people objection, the 
only point of contention was where to package the debug symbols. How do 
you propropose to solve the problem that the .a files are huge?
Also, you don't mention any problems, you only say "I [..] think", which 
usually isn't a good enough reason to revert stuff :)

regards,

Koen

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

[Holger Hans Peter Freyther]

On Friday 23 October 2009 09:23:03 Koen Kooi wrote:

> > I don't think we need to strip .a files as they will not end on the
> > device
> 
> They do actually
> 
> > and people will link their binaries to them and we will strip the
> > binaries.
> 
> There was a discussion about that and I didn't see people objection, the
> only point of contention was where to package the debug symbols. How do
> you propropose to solve the problem that the .a files are huge?
> Also, you don't mention any problems, you only say "I [..] think", which
> usually isn't a good enough reason to revert stuff :)

The above commits cause build problems and break the "toolchain" (native, 
cross-sdk) at runtime. The toolchain is broken as all symbols are stripped out 
of the libc_nonshared.a.

Why do you need .a files on the device? Is this normal operation or only when 
installing -dev packages?

z.

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

[Koen Kooi]

On 23-10-09 09:30, Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 09:23:03 Koen Kooi wrote:
>
>>> I don't think we need to strip .a files as they will not end on the
>>> device
>>
>> They do actually
>>
>>> and people will link their binaries to them and we will strip the
>>> binaries.
>>
>> There was a discussion about that and I didn't see people objection, the
>> only point of contention was where to package the debug symbols. How do
>> you propropose to solve the problem that the .a files are huge?
>> Also, you don't mention any problems, you only say "I [..] think", which
>> usually isn't a good enough reason to revert stuff :)
>
> The above commits cause build problems and break the "toolchain" (native,
> cross-sdk) at runtime. The toolchain is broken as all symbols are stripped out
> of the libc_nonshared.a.

Ah, that's not nice

> Why do you need .a files on the device? Is this normal operation or only when
> installing -dev packages?

When installing -dev packages, yes. For example on the touchbook default 
image we ship a toolchain and -dev packages for clutter to allow people 
to build things on the target. By stripping the .a files we save about 
200MiB.

I can think of a few solutions:

* build toolchain packages with -ggdbN where N < 3
* use a safer stripping option in package.bbclass
* blacklist libc_nonshared.a

Do you have more solutions and which do you prefer? I really like to 
avoid blowing up -dev packages if we can safely strip (most of) them.

regards,

Koen

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

[Holger Hans Peter Freyther]

On Friday 23 October 2009 09:58:28 Koen Kooi wrote:

> > Why do you need .a files on the device? Is this normal operation or only
> > when installing -dev packages?
> 
> When installing -dev packages, yes. For example on the touchbook default
> image we ship a toolchain and -dev packages for clutter to allow people
> to build things on the target. By stripping the .a files we save about
> 200MiB.
> 
> I can think of a few solutions:
> 
> * build toolchain packages with -ggdbN where N < 3
> * use a safer stripping option in package.bbclass
> * blacklist libc_nonshared.a
> 
> Do you have more solutions and which do you prefer? I really like to
> avoid blowing up -dev packages if we can safely strip (most of) them.

I see. Yeah the -ggdb3 can make things quite big. The problem is if I want to 
link statically and debug having debug symbols and symbols around is quite 
helpful. Currently the .a files are just plain broken (worse than not 
installing).

One thing that pops back into my mind is to move .a files into a -static 
package? People that want to link statically can pick their .a files.

z.

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

[Phil Blundell]

On Fri, 2009-10-23 at 10:23 +0200, Holger Hans Peter Freyther wrote:
> One thing that pops back into my mind is to move .a files into a -static 
> package? People that want to link statically can pick their .a files.

Yes, I think someone else proposed this a few weeks ago but it doesn't
seem to have happened.  Given that static linking is pretty much a
minority pursuit nowadays (excepting libc_noshared.a) this sounds like a
fine idea.

Stripping .a files with the default options will effectively destroy
them so the current state of affairs is definitely silly.  If you are
going to do that then you might as well just delete the files: they are
no use for anything after stripping.

An alternative (or an addition) to the -static packaging would be to
arrange for .a files (and .o files, I guess) to be stripped with "strip
--strip-debug" (or perhaps --strip-unneeded).  This should leave enough
symbol data in the files for them to remain usable.  

p.

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

[Koen Kooi]

On 23-10-09 10:36, Phil Blundell wrote:
> On Fri, 2009-10-23 at 10:23 +0200, Holger Hans Peter Freyther wrote:
>> One thing that pops back into my mind is to move .a files into a -static
>> package? People that want to link statically can pick their .a files.
>
> Yes, I think someone else proposed this a few weeks ago but it doesn't
> seem to have happened.  Given that static linking is pretty much a
> minority pursuit nowadays (excepting libc_noshared.a) this sounds like a
> fine idea.
>
> Stripping .a files with the default options will effectively destroy
> them so the current state of affairs is definitely silly.  If you are
> going to do that then you might as well just delete the files: they are
> no use for anything after stripping.
>
> An alternative (or an addition) to the -static packaging would be to
> arrange for .a files (and .o files, I guess) to be stripped with "strip
> --strip-debug" (or perhaps --strip-unneeded).  This should leave enough
> symbol data in the files for them to remain usable.

Something like this (but without the mailer induced linewrapping)?

diff --git a/classes/package.bbclass b/classes/package.bbclass
index 046351a..2bf55e3 100644
--- a/classes/package.bbclass
+++ b/classes/package.bbclass
@@ -183,6 +183,9 @@ def runstrip(file, d):
          extraflags = "--remove-section=.comment --remove-section=.note 
--strip-unneeded"
      elif "shared" in result or "executable" in result:
          extraflags = "--remove-section=.comment --remove-section=.note"
+       elif file.endswith(".a")::
+                extraflags = "--remove-section=.comment --strip-debug"
+

      bb.mkdirhier(os.path.join(os.path.dirname(file), ".debug"))
      debugfile=os.path.join(os.path.dirname(file), ".debug", 
os.path.basename(file))
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 7426095..6c1cc06 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -207,7 +207,7 @@ SOLIBSDEV_darwin = ".dylib"
  SOLIBSDEV_darwin8 = ".dylib"
  SOLIBSDEV_darwin9 = ".dylib"

-PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-locale"
+PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-static ${PN}-dev ${PN}-locale"
  #enable this when bitbake is upgraded to cope with ++ values in the field
  PACKAGES_DYNAMIC = "${PN}-locale-*"
  FILES = ""
@@ -225,9 +225,11 @@ FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} 
${datadir}/gtk-doc \
              ${datadir}/gnome/help"
  SECTION_${PN}-doc = "doc"

+FILES_${PN}-static = "${libdir}/*.a ${base_libdir}/*.a"
+
  FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} 
${libdir}/*.la \
-                ${libdir}/*.a ${libdir}/*.o ${libdir}/pkgconfig \
-                ${base_libdir}/*.a ${base_libdir}/*.o 
${datadir}/aclocal ${datadir}/pkgconfig"
+                ${libdir}/*.o ${libdir}/pkgconfig \
+                ${base_libdir}/*.o ${datadir}/aclocal ${datadir}/pkgconfig"
  SECTION_${PN}-dev = "devel"
  ALLOW_EMPTY_${PN}-dev = "1"
  RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPV})"


regards,

Koen

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

[Holger Hans Peter Freyther]

On Friday 23 October 2009 11:14:48 Koen Kooi wrote:
> On 23-10-09 10:36, Phil Blundell wrote:

> > An alternative (or an addition) to the -static packaging would be to
> > arrange for .a files (and .o files, I guess) to be stripped with "strip
> > --strip-debug" (or perhaps --strip-unneeded).  This should leave enough
> > symbol data in the files for them to remain usable.
> 
> Something like this (but without the mailer induced linewrapping)?
> 
> diff --git a/classes/package.bbclass b/classes/package.bbclass
> index 046351a..2bf55e3 100644
> --- a/classes/package.bbclass
> +++ b/classes/package.bbclass
> @@ -183,6 +183,9 @@ def runstrip(file, d):
>           extraflags = "--remove-section=.comment --remove-section=.note
> --strip-unneeded"
>       elif "shared" in result or "executable" in result:
>           extraflags = "--remove-section=.comment --remove-section=.note"
> +       elif file.endswith(".a")::

one colon  please :)



> +                extraflags = "--remove-section=.comment --strip-debug"
> +

and I would prefer to have debug symbols in there. you can always strip them 
out of the final binary but you can not add them when they are gone.

The last bit is that I would like to put /usr/lib/libc_nonshared.a into the 
libc-dev package


z.

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

[Koen Kooi]

On 23-10-09 11:33, Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 11:14:48 Koen Kooi wrote:
>> On 23-10-09 10:36, Phil Blundell wrote:
>
>>> An alternative (or an addition) to the -static packaging would be to
>>> arrange for .a files (and .o files, I guess) to be stripped with "strip
>>> --strip-debug" (or perhaps --strip-unneeded).  This should leave enough
>>> symbol data in the files for them to remain usable.
>>
>> Something like this (but without the mailer induced linewrapping)?
>>
>> diff --git a/classes/package.bbclass b/classes/package.bbclass
>> index 046351a..2bf55e3 100644
>> --- a/classes/package.bbclass
>> +++ b/classes/package.bbclass
>> @@ -183,6 +183,9 @@ def runstrip(file, d):
>>            extraflags = "--remove-section=.comment --remove-section=.note
>> --strip-unneeded"
>>        elif "shared" in result or "executable" in result:
>>            extraflags = "--remove-section=.comment --remove-section=.note"
>> +       elif file.endswith(".a")::
>
> one colon  please :)

Right :)

>> +                extraflags = "--remove-section=.comment --strip-debug"
>> +
>
> and I would prefer to have debug symbols in there. you can always strip them
> out of the final binary but you can not add them when they are gone.

Installing foo-dbg doesn't work?

> The last bit is that I would like to put /usr/lib/libc_nonshared.a into the
> libc-dev package

Glibc has its own custom packaging, which we'll probably need to tweaks 
as well.

Anyways, I'll start accumulating patches in 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=koen/static-libs-rework 
and change those to work in all your comments.

regards,

Koen

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

[Holger Hans Peter Freyther]

On Friday 23 October 2009 11:46:22 Koen Kooi wrote:

> > and I would prefer to have debug symbols in there. you can always strip
> > them out of the final binary but you can not add them when they are gone.
> 
> Installing foo-dbg doesn't work?

It will not. At least from my understanding of an .a archive. You will need to 
get the symbols into the binary when statically linking, this will not happen 
when they are in a .debug/liba.a.

Does this sound correct?

	z.

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

[Koen Kooi]

On 23-10-09 11:54, Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 11:46:22 Koen Kooi wrote:
>
>>> and I would prefer to have debug symbols in there. you can always strip
>>> them out of the final binary but you can not add them when they are gone.
>>
>> Installing foo-dbg doesn't work?
>
> It will not. At least from my understanding of an .a archive. You will need to
> get the symbols into the binary when statically linking, this will not happen
> when they are in a .debug/liba.a.

If that's the case, we shouldn't be stripping static libs.

I updated 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=koen/static-libs-rework

If those changes look OK, I'll start going to recipes with custom 
packaging (e.g. qt4) and have them put static libs -static as well.

And I see a DISTRO_PR bump coming for angstrom.

regards,

Koen

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

[Phil Blundell]

On Fri, 2009-10-23 at 11:54 +0200, Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 11:46:22 Koen Kooi wrote:
> 
> > > and I would prefer to have debug symbols in there. you can always strip
> > > them out of the final binary but you can not add them when they are gone.
> > 
> > Installing foo-dbg doesn't work?
> 
> It will not. At least from my understanding of an .a archive. You will need to 
> get the symbols into the binary when statically linking, this will not happen 
> when they are in a .debug/liba.a.
> 
> Does this sound correct?

Yes, that is correct.  In theory it would be possible to splice the
debug data back into the binary, or to teach gdb how to read debug
symbols out of the individual .debug records for the archive components,
or indeed to teach g(o)ld to pull in debug data in the way that you
suggest during final link of a binary, but I don't think the existing
tools can do any of those things.

p.

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

[Stanislav Brabec]

Koen Kooi wrote:
> On 23-10-09 11:33, Holger Hans Peter Freyther wrote:

> > The last bit is that I would like to put /usr/lib/libc_nonshared.a into the
> > libc-dev package
> 
> Glibc has its own custom packaging, which we'll probably need to tweaks 
> as well.

I think that the logic should be:

libfoo.a exists and libfoo.so exists => put .a to -static.

libfoo.a exists and libfoo.so does not exist => put .a to -dev.

This logic will work as most users expect and will need no exception for
glibc.


But I would do even one step forward:

In last 12 years I did not need any of system static library instances.
With exception of bootloader authors, almost nobody else needs static
libraries.

That is why I would like to introduce new global default:
--disable-static (via variable, site config or so).

Only packages that explicitly require or explicitly build the static
library will have them (in -dev or -static sub-package, see above).

Distributions that build all-in-one binary can enable it in the
per-distro config, all other distros will remain without nearly all
static libraries.

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

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

[Holger Hans Peter Freyther]

On Friday 23 October 2009 13:07:06 Stanislav Brabec wrote:
> Koen Kooi wrote:
> > On 23-10-09 11:33, Holger Hans Peter Freyther wrote:
> > > The last bit is that I would like to put /usr/lib/libc_nonshared.a into
> > > the libc-dev package
> >
> > Glibc has its own custom packaging, which we'll probably need to tweaks
> > as well.
> 
> I think that the logic should be:
> 
> libfoo.a exists and libfoo.so exists => put .a to -static.
> 
> libfoo.a exists and libfoo.so does not exist => put .a to -dev.
> 
> This logic will work as most users expect and will need no exception for
> glibc.

This will add even more python code to package.bbclass and can not be realized 
with a FILES_* change. I would prefer a stupid QA check for that as I don't 
expect this to happen on many packages.


z.

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

[Stanislav Brabec]

Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 13:07:06 Stanislav Brabec wrote:

> > I think that the logic should be:
> > 
> > libfoo.a exists and libfoo.so exists => put .a to -static.
> > 
> > libfoo.a exists and libfoo.so does not exist => put .a to -dev.
> > 
> > This logic will work as most users expect and will need no exception for
> > glibc.
> 
> This will add even more python code to package.bbclass and can not be realized 
> with a FILES_* change. I would prefer a stupid QA check for that as I don't 
> expect this to happen on many packages.

That it will happen for all packages that don't provide shared library.
These packages may end by broken -dev package with just the
*.a => -static rule.

I am not sure, how many such packages exist in the tree, but here is a
list of files in my work directory that would need special care:

alsa-oss-1.0.17-r0: /usr/lib/libossredir.a
binutils-2.18-r8.1: /usr/lib/libiberty.a
bison-2.3-r0: /usr/lib/liby.a
bridge-utils-1.4-r0: /usr/lib/libbridge.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libnss.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libnssutil.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libunicharutil_external_s.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libembed_base_standalone.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libsoftokn.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libssl.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libembed_base_s.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libcrmf.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libsmime.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libxpcomglue_s.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libmozreg_s.a
firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libxpcomglue.a
flex-2.5.31-r4: /usr/lib/libfl.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib64/libiberty.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libgfortran.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libssp.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libiberty.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libstdc++_pic.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libssp_nonshared.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libsupc++.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libstdc++.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc_eh.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgfortranbegin.a
gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcov.a
gcc-4.3.3-r7.1: /usr/lib/libstdc++_pic.a
gcc-4.3.3-r7.1: /usr/lib/libssp_nonshared.a
gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a
gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc_eh.a
gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgfortranbegin.a
gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcov.a
gcc-4.3.3-r7.1: /usr/lib/libsupc++.a
gdb-7.0-r0: /usr/lib/libbfd.a
gdb-7.0-r0: /usr/lib/libopcodes.a
gdb-7.0-r0: /usr/lib/libiberty.a
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
libassuan-0.6.9-r0: /usr/lib/libassuan.a
libatomics-ops-1.2-r2: /usr/lib/libatomic_ops_gpl.a
libatomics-ops-1.2-r2: /usr/lib/libatomic_ops.a
libsdl-x11-1.2.11-r8: /usr/lib/libSDLmain.a
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
orbit2-2.14.17-r0: /usr/lib/libname-server-2.a
perl-5.8.8-r28: /usr/lib/perl/5.8.8/auto/DynaLoader/DynaLoader.a
python-2.6.1-ml8.0: /usr/lib/python2.6/config/libpython2.6.a
tcl-8.4.19-r2: /usr/lib/libtclstub8.4.a
tk-8.4.19-r0: /usr/lib/libtkstub8.4.a
tcl-native-8.4.19-r2: /OE/build/tmp/staging/x86_64-linux/usr/lib/libtclstub8.4.a
tk-native-8.4.19-r0: /OE/build/tmp/staging/x86_64-linux/usr/lib/libtkstub8.4.a

Found by this bash command:
find */*/image -name '*.a' | fgrep -v .debug | while read ; do if ! test -f "${REPLY%.a}.so" ; then PKG=$REPLY ; PKG=${PKG#*/} ; PKG=${PKG%%/*} ; echo $PKG: ${REPLY#*/image} ; fi ; done


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

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

[Khem Raj]

On Fri, Oct 23, 2009 at 3:31 PM, Stanislav Brabec <utx@penguin.cz> wrote:
> Holger Hans Peter Freyther wrote:
>> On Friday 23 October 2009 13:07:06 Stanislav Brabec wrote:
>
>> > I think that the logic should be:
>> >
>> > libfoo.a exists and libfoo.so exists => put .a to -static.
>> >
>> > libfoo.a exists and libfoo.so does not exist => put .a to -dev.
>> >
>> > This logic will work as most users expect and will need no exception for
>> > glibc.
>>
>> This will add even more python code to package.bbclass and can not be realized
>> with a FILES_* change. I would prefer a stupid QA check for that as I don't
>> expect this to happen on many packages.
>
> That it will happen for all packages that don't provide shared library.
> These packages may end by broken -dev package with just the
> *.a => -static rule.
>
> I am not sure, how many such packages exist in the tree, but here is a
> list of files in my work directory that would need special care:
>
> alsa-oss-1.0.17-r0: /usr/lib/libossredir.a
> binutils-2.18-r8.1: /usr/lib/libiberty.a
> bison-2.3-r0: /usr/lib/liby.a
> bridge-utils-1.4-r0: /usr/lib/libbridge.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libnss.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libnssutil.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libunicharutil_external_s.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libembed_base_standalone.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libsoftokn.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libssl.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libembed_base_s.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libcrmf.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libsmime.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libxpcomglue_s.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libmozreg_s.a
> firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libxpcomglue.a
> flex-2.5.31-r4: /usr/lib/libfl.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib64/libiberty.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libgfortran.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libssp.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libiberty.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libstdc++_pic.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libssp_nonshared.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libsupc++.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libstdc++.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc_eh.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgfortranbegin.a
> gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcov.a
> gcc-4.3.3-r7.1: /usr/lib/libstdc++_pic.a
> gcc-4.3.3-r7.1: /usr/lib/libssp_nonshared.a
> gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a
> gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc_eh.a
> gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgfortranbegin.a
> gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcov.a
> gcc-4.3.3-r7.1: /usr/lib/libsupc++.a
> gdb-7.0-r0: /usr/lib/libbfd.a
> gdb-7.0-r0: /usr/lib/libopcodes.a
> gdb-7.0-r0: /usr/lib/libiberty.a
> 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
> libassuan-0.6.9-r0: /usr/lib/libassuan.a
> libatomics-ops-1.2-r2: /usr/lib/libatomic_ops_gpl.a
> libatomics-ops-1.2-r2: /usr/lib/libatomic_ops.a
> libsdl-x11-1.2.11-r8: /usr/lib/libSDLmain.a
> 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
> orbit2-2.14.17-r0: /usr/lib/libname-server-2.a
> perl-5.8.8-r28: /usr/lib/perl/5.8.8/auto/DynaLoader/DynaLoader.a
> python-2.6.1-ml8.0: /usr/lib/python2.6/config/libpython2.6.a
> tcl-8.4.19-r2: /usr/lib/libtclstub8.4.a
> tk-8.4.19-r0: /usr/lib/libtkstub8.4.a
> tcl-native-8.4.19-r2: /OE/build/tmp/staging/x86_64-linux/usr/lib/libtclstub8.4.a
> tk-native-8.4.19-r0: /OE/build/tmp/staging/x86_64-linux/usr/lib/libtkstub8.4.a
>
> Found by this bash command:
> find */*/image -name '*.a' | fgrep -v .debug | while read ; do if ! test -f "${REPLY%.a}.so" ; then PKG=$REPLY ; PKG=${PKG#*/} ; PKG=${PKG%%/*} ; echo $PKG: ${REPLY#*/image} ; fi ; done


I think we should only fix glibc case here as it is special.
 libc_nonshared.a has objects not available in the dynamic C library
(libc.so.6) necessary for dynamically linking some binaries.
as we have seen in this case. I dont think this case will be common
for other packages. So even if stripping is necessary we should
add code to identify  libc_nonshared.a and avoid stripping it as special case.

Thanks

-Khem

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

[Koen Kooi]

On 24-10-09 00:31, Stanislav Brabec wrote:
> Holger Hans Peter Freyther wrote:
>> On Friday 23 October 2009 13:07:06 Stanislav Brabec wrote:
>
>>> I think that the logic should be:
>>>
>>> libfoo.a exists and libfoo.so exists =>  put .a to -static.
>>>
>>> libfoo.a exists and libfoo.so does not exist =>  put .a to -dev.
>>>
>>> This logic will work as most users expect and will need no exception for
>>> glibc.
>>
>> This will add even more python code to package.bbclass and can not be realized
>> with a FILES_* change. I would prefer a stupid QA check for that as I don't
>> expect this to happen on many packages.
>
> That it will happen for all packages that don't provide shared library.
> These packages may end by broken -dev package with just the
> *.a =>  -static rule.

Actually it's /lib/*.a,/usr/lib/*.a -> static, which means...


> I am not sure, how many such packages exist in the tree, but here is a
> list of files in my work directory that would need special care:

... becomes a bit smaller:


> alsa-oss-1.0.17-r0: /usr/lib/libossredir.a
> binutils-2.18-r8.1: /usr/lib/libiberty.a
> bison-2.3-r0: /usr/lib/liby.a
> bridge-utils-1.4-r0: /usr/lib/libbridge.a

> flex-2.5.31-r4: /usr/lib/libfl.a

> gcc-4.3.3-r7.1: /usr/lib/libstdc++_pic.a
> gcc-4.3.3-r7.1: /usr/lib/libssp_nonshared.a

> gcc-4.3.3-r7.1: /usr/lib/libsupc++.a
> gdb-7.0-r0: /usr/lib/libbfd.a
> gdb-7.0-r0: /usr/lib/libopcodes.a
> gdb-7.0-r0: /usr/lib/libiberty.a
> 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
> libassuan-0.6.9-r0: /usr/lib/libassuan.a
> libatomics-ops-1.2-r2: /usr/lib/libatomic_ops_gpl.a
> libatomics-ops-1.2-r2: /usr/lib/libatomic_ops.a
> libsdl-x11-1.2.11-r8: /usr/lib/libSDLmain.a
> 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
> orbit2-2.14.17-r0: /usr/lib/libname-server-2.a

> tcl-8.4.19-r2: /usr/lib/libtclstub8.4.a
> tk-8.4.19-r0: /usr/lib/libtkstub8.4.a

I would be happy to take special care of the above recipe in my fixup 
branch. Do we all agree that the above .a files need to go into -dev 
packages? If so I'll add something like FILES_${PN}-static = "" to the 
affected recipes


And these wouldn't need special handling:

 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libnss.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libnssutil.a
 > firefox-3.5.2-r2: 
/usr/lib/firefox-devel-3.5.2/sdk/lib/libunicharutil_external_s.a
 > firefox-3.5.2-r2: 
/usr/lib/firefox-devel-3.5.2/sdk/lib/libembed_base_standalone.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libsoftokn.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libssl.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libembed_base_s.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libcrmf.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libsmime.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libxpcomglue_s.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libmozreg_s.a
 > firefox-3.5.2-r2: /usr/lib/firefox-devel-3.5.2/sdk/lib/libxpcomglue.a
 > gcc-cross-4.3.3-r7.1: /OE/build/tmp/cross/armv5te/lib64/libiberty.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libgfortran.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libssp.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libiberty.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libstdc++_pic.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libssp_nonshared.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libsupc++.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/arm-angstrom-linux-gnueabi/lib/libstdc++.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc_eh.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgfortranbegin.a
 > gcc-cross-4.3.3-r7.1: 
/OE/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcov.a
 > perl-5.8.8-r28: /usr/lib/perl/5.8.8/auto/DynaLoader/DynaLoader.a
 > python-2.6.1-ml8.0: /usr/lib/python2.6/config/libpython2.6.a
 > tcl-native-8.4.19-r2: 
/OE/build/tmp/staging/x86_64-linux/usr/lib/libtclstub8.4.a
 > tk-native-8.4.19-r0: 
/OE/build/tmp/staging/x86_64-linux/usr/lib/libtkstub8.4.a
 > gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a
 > gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc_eh.a
 > gcc-4.3.3-r7.1: 
/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgfortranbegin.a
 > gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcov.a

regards,

Koen

> Found by this bash command:
> find */*/image -name '*.a' | fgrep -v .debug | while read ; do if ! test -f "${REPLY%.a}.so" ; then PKG=$REPLY ; PKG=${PKG#*/} ; PKG=${PKG%%/*} ; echo $PKG: ${REPLY#*/image} ; fi ; done
>
>
> ________________________________________________________________________
> Stanislav Brabec
> http://www.penguin.cz/~utx/zaurus
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

[Stanislav Brabec]

On Oct 24, 2009 at 10:48:22 Koen Kooi wrote:
> 
> I would be happy to take special care of the above recipe in my fixup 
> branch. Do we all agree that the above .a files need to go into -dev 
> packages? If so I'll add something like FILES_${PN}-static = "" to 
> the
> 
> affected recipes

All mentioned libraries above must go to -dev or -sdk, otherwise you
will not be able to build against them without -static installled.

FILES_${PN}-static = "" is not fully correct general solution. There
are projects, that have more static libraries. Only listed static
libraries must go to -dev, the rest may go to -static. A good
example is libsdl-x11. Only libSDLmain.a must go to -dev, the rest may
go to -static. I'll try to create smarter expression to find such
packages.

Note that this list covers only packages actually built for my image.

> And these wouldn't need special handling:

All of them probably would need. For example without libgcc.a you will
not be able to compile.

>  > gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/
> libgcc.a

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

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

[Stanislav Brabec]

Stanislav Brabec wrote:

> FILES_${PN}-static = "" is not fully correct general solution. There
> are projects, that have more static libraries. Only listed static
> libraries must go to -dev, the rest may go to -static. A good
> example is libsdl-x11. Only libSDLmain.a must go to -dev, the rest
SDL is not a good example, orbit2 is a better example.

Being able to write ${PN}-dev += "${libdir}/libfoo.a" instead of  
overwriting of
${PN}-static with a negative expression would be more comfortable. I  
guess that it depends only on the order of evaluation in the bbclass  
file.

The QA test should be:
libfoo.a is in -static but libfoo.so does not exist => issue fatal QA  
error with
proposed fix: move libfoo.a e. g. to -dev.

Note that libgcc.a has to go to the main package. Even -dev is not  
correct here.

Here is a new bash command and its output:

utx@/OE/build/tmp/work> find */*/image -name '*.a' | fgrep -v .debug |  
while read ; do if ! test -f "${REPLY%.a}.so" ; then PKG=$REPLY ;  
PKG=${PKG#*/} ; PKG=${PKG%%/*} ; echo
$PKG ; fi ; done | uniq -c | while read COUNT PKG ; do XCOUNT=$(find  
*/$PKG/image -name '*.a' | fgrep -v .debug | wc -l) ; echo -n $PKG:  
$XCOUNT static total, $COUNT static unique ; if test $COUNT -eq $XCOUNT  
; then echo ' => can use simple expression' ; else echo ' => needs  
complex expression' ; fi ; done
alsa-oss-1.0.17-r0: 3 static total, 1 static unique => needs complex  
expression
binutils-2.18-r8.1: 3 static total, 1 static unique => needs complex  
expression
bison-2.3-r0: 1 static total, 1 static unique => can use simple  
expression
bridge-utils-1.4-r0: 1 static total, 1 static unique => can use simple  
expression
firefox-3.5.2-r2: 12 static total, 12 static unique => can use simple  
expression
flex-2.5.31-r4: 1 static total, 1 static unique => can use simple  
expression
gcc-cross-4.3.3-r7.1: 12 static total, 12 static unique => can use  
simple expression
gcc-4.3.3-r7.1: 10 static total, 7 static unique => needs complex  
expression
gdb-7.0-r0: 3 static total, 3 static unique => can use simple expression
glibc-2.9-r35.2: 17 static total, 6 static unique => needs complex  
expression
libassuan-0.6.9-r0: 1 static total, 1 static unique => can use simple  
expression
libatomics-ops-1.2-r2: 2 static total, 2 static unique => can use  
simple expression
libsdl-x11-1.2.11-r8: 1 static total, 1 static unique => can use simple  
expression
mysql-4.1.22-r3: 11 static total, 10 static unique => needs complex  
expression
orbit2-2.14.17-r0: 5 static total, 1 static unique => needs complex  
expression
perl-5.8.8-r28: 1 static total, 1 static unique => can use simple  
expression
python-2.6.1-ml8.0: 1 static total, 1 static unique => can use simple  
expression
tcl-8.4.19-r2: 1 static total, 1 static unique => can use simple  
expression
tk-8.4.19-r0: 1 static total, 1 static unique => can use simple  
expression
tcl-native-8.4.19-r2: 1 static total, 1 static unique => can use simple  
expression
tk-native-8.4.19-r0: 1 static total, 1 static unique => can use simple  
expression

The simple expression can be .../*.a in -dev (or -sdk or so) or  
emptying of -static.

gcc may need special care and double thinking. But I guess that the  
logic: "Do you want to compile static binaries? Install gcc-static." is  
valid here as well.

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

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

[Phil Blundell]

On Sat, 2009-10-24 at 16:13 +0200, Stanislav Brabec wrote:
> gcc may need special care and double thinking. But I guess that the  
> logic: "Do you want to compile static binaries? Install gcc-static." is  
> valid here as well.

That logic does indeed make sense, though I think on most DISTROs there
would be nothing useful to put in gcc-static.  You could relegate
libgcc.a there if your gcc configuration had --shared-libgcc as default,
but I don't think many/any DISTROs are doing that at present.  (I've
been considering it for micro but I haven't had time to actually make
the change.)

p.

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

[Koen Kooi]

On 24-10-09 15:27, Stanislav Brabec wrote:

>> And these wouldn't need special handling:
>
> All of them probably would need. For example without libgcc.a you will
> not be able to compile.
>
>>   >  gcc-4.3.3-r7.1: /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/
>> libgcc.a

Now please pay attention, since I'm saying this for the second time now:

"Actually it's /lib/*.a,/usr/lib/*.a -> static"

So /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/libgcc.a won't go into 
-static since it doesn't match /lib/*.a,/usr/lib/*.a

regards,

Koen

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

[Phil Blundell]

On Sat, 2009-10-24 at 10:48 +0200, Koen Kooi wrote:
> On 24-10-09 00:31, Stanislav Brabec wrote:
> > alsa-oss-1.0.17-r0: /usr/lib/libossredir.a
> > 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.

> > 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.

> > 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.

> > flex-2.5.31-r4: /usr/lib/libfl.a

This is like bison.

> > 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.

> > 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.

> > 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.

> > 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.

p.

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

[Koen Kooi]

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


>>> 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.

I put that in ${PN}: 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=koen/static-libs-rework


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

Ditto: 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=koen/static-libs-rework


>>> 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.

Gcc-package-*.inc overrides PACKAGES, so these won't be affected.

>>> 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.

Already did that: 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=koen/static-libs-rework

I can run stanislavs scripts after the weekend to see if there are 
anymore special packages.

For people like Holger: you can add 
git://dominion.thruhere.net/var/cache/git/openembedded.git as a remote 
and fetch my branch from there.

regards,

Koen

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

[Stanislav Brabec]

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

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

[Phil Blundell]

On Sat, 2009-10-24 at 17:39 +0200, Stanislav Brabec wrote:
> 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.

Yeah, you could do that if you wanted.  Debian doesn't seem to ship it
which suggests that there isn't a great deal of demand for such a thing,
but it would be harmless enough.

> > 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).

Right, but it isn't entirely obvious to me why one would (in general)
want to install such a library.  Do you know what the actual use-case
for libstdc++_pic is?  If this is for mklibs-style library reduction
then it probably belongs in yet another subpackage if anywhere.

p.

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

[Stanislav Brabec]

Phil Blundell wrote:
> but it isn't entirely obvious to me why one would (in general)
> want to install such a library.  Do you know what the actual use-case
> for libstdc++_pic is?  If this is for mklibs-style library reduction
> then it probably belongs in yet another subpackage if anywhere.

I guess that it makes possible to create libraries that are written in
C++ but don't depend on libstdc++. It also contains PIC code of
libsupc++.

Reference: /OE/build/static/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-4.3.3-r7.1/gcc-4.3.3/libstdc++-v3/src/Makefile.am

_pic.a libraries are typically useful for large convoluted libraries
containing many independent function sets, e. g. mathematical libraries.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

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

[Leon Woestenberg]

On Fri, Oct 23, 2009 at 1:07 PM, Stanislav Brabec <utx@penguin.cz> wrote:
> But I would do even one step forward:
> In last 12 years I did not need any of system static library instances.
>
I did, I do not see disabling static libraries as a step forward.

Not that I really really NEEDED it, but it reduced the footprint,
boot/link/load time on a single process firmware application to such
an amount that static linking was desired.

> With exception of bootloader authors, almost nobody else needs static
> libraries.
>
Static linking is a valid approach for embedded use, let's not cripple it more.

I think we should build most of what we can build during the compile
and install and stage tasks, then reduce what we need in later stages.

> That is why I would like to introduce new global default:
> --disable-static (via variable, site config or so).
>
> Only packages that explicitly require or explicitly build the static
> library will have them (in -dev or -static sub-package, see above).
>
Typically libraries should stage the static, so that dependent
packages can choose to statically link against them.

I would keep the discussing on how to package statics and their
corresponding debug info.

Regards,
-- 
Leon

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

[Phil Blundell]

On Fri, 2009-10-23 at 13:07 +0200, Stanislav Brabec wrote:
> I think that the logic should be:
> 
> libfoo.a exists and libfoo.so exists => put .a to -static.
> 
> libfoo.a exists and libfoo.so does not exist => put .a to -dev.
> 
> This logic will work as most users expect and will need no exception for
> glibc.

I agree that this logic would give you the optimum results in all cases,
but I am not sure that it is worth the trouble to implement.  There are
hardly any packages that ship static-only libraries and most (perhaps
all) of the ones that do are most likely doing so for erroneous reasons.
The remaining packages that ship static-only libraries for good reason
are almost certainly few enough in number that they could be fixed up
individually.

> That is why I would like to introduce new global default:
> --disable-static (via variable, site config or so).

That sounds like a fine idea to me.  I'm not so sure about making it the
default, but providing an easy switch that DISTROs can use to turn off
static libraries globally would be a good plan.

p.

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

[Koen Kooi]

On 23-10-09 11:33, Holger Hans Peter Freyther wrote:

> The last bit is that I would like to put /usr/lib/libc_nonshared.a into the
> libc-dev package

How does this look to you: 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/log/?h=koen/static-libs-rework

 From 3846a3fd24746db0f9d1c28fad70761f6ef6a9a4 Mon Sep 17 00:00:00 2001
From: Koen Kooi <koen@openembedded.org>
Date: Fri, 23 Oct 2009 12:19:50 +0000
Subject: glibc package bbclass: tweak library packaging

Static libs move around a bit:

glibc-dev:
/usr/lib/libpthread_nonshared.a
/usr/lib/libc_nonshared.a

glibc-static:
/usr/lib/libm.a
/usr/lib/libbsd-compat.a
/usr/lib/libanl.a
/usr/lib/libpthread.a
/usr/lib/libcrypt.a
/usr/lib/libresolv.a
/usr/lib/libutil.a
/usr/lib/libieee.a
/usr/lib/librt.a
/usr/lib/libnsl.a
/usr/lib/libdl.a
/usr/lib/libc.a
/usr/lib/libmcheck.a
/usr/lib/libBrokenLocale.a
/usr/lib/libg.a
---
diff --git a/recipes/glibc/glibc-package.bbclass 
b/recipes/glibc/glibc-package.bbclass
index 4d7f6fd..708f044 100644
--- a/recipes/glibc/glibc-package.bbclass
+++ b/recipes/glibc/glibc-package.bbclass
@@ -29,19 +29,19 @@ BINARY_LOCALE_ARCHES ?= "arm.* i[3-6]86 x86_64 powerpc"
  # Set this to zero if you don't want ldconfig in the output package
  USE_LDCONFIG ?= "1"

-PACKAGES = "glibc-dbg glibc catchsegv sln nscd ldd localedef 
glibc-utils glibc-dev glibc-doc glibc-locale libsegfault glibc-extra-nss 
glibc-thread-db glibc-pcprofile"
+PACKAGES = "glibc-dbg glibc catchsegv sln nscd ldd localedef 
glibc-utils glibc-dev glibc-static glibc-doc glibc-locale libsegfault 
glibc-extra-nss glibc-thread-db glibc-pcprofile"
  PACKAGES_DYNAMIC = "glibc-gconv-* glibc-charmap-* glibc-localedata-* 
locale-base-* glibc-binary-localedata-*"

  INSANE_SKIP_glibc-dbg = True

-libc_baselibs = "${base_libdir}/libcrypt*.so.* 
${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
+libc_baselibs = "${base_libdir}/libcrypt*.so.* 
${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so 
${base_libdir}/libcidn-*.so  ${base_libdir}/libmemusage.so"

  FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${datadir}/zoneinfo 
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig', '', 
d)}"
  FILES_ldd = "${bindir}/ldd"
  FILES_libsegfault = "${base_libdir}/libSegFault*"
  FILES_glibc-extra-nss = "${base_libdir}/libnss*"
  FILES_sln = "${base_sbindir}/sln"
-FILES_glibc-dev_append = " ${libdir}/*.o ${bindir}/rpcgen"
+FILES_glibc-dev_append = " ${libdir}/*.o ${bindir}/rpcgen 
${libdir}/*non_shared.a"
  FILES_nscd = "${sbindir}/nscd* ${sysconfdir}/nscd* 
${sysconfdir}/init.d/nscd*"
  FILES_glibc-utils = "${bindir}/* ${sbindir}/*"
  FILES_glibc-gconv = "${libdir}/gconv/*"
--
cgit v0.8.2.1-10-g45e7

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

[Phil Blundell]

On Fri, 2009-10-23 at 14:28 +0200, Koen Kooi wrote:
> -FILES_glibc-dev_append = " ${libdir}/*.o ${bindir}/rpcgen"
> +FILES_glibc-dev_append = " ${libdir}/*.o ${bindir}/rpcgen 
> ${libdir}/*non_shared.a"

That doesn't look right.  I think it's "_nonshared", not "non_shared".

p.

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

[Phil Blundell]

On Fri, 2009-10-23 at 14:28 +0200, Koen Kooi wrote:
> -libc_baselibs = "${base_libdir}/libcrypt*.so.* 
> ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
> ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
> ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
> +libc_baselibs = "${base_libdir}/libcrypt*.so.* 
> ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
> ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
> ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so 
> ${base_libdir}/libcidn-*.so  ${base_libdir}/libmemusage.so"

It took me a moment to spot what was actually happening here, but I
think this is a step in the wrong direction.  Libmemusage is not
something that most folks are going to want in their rootfs; libcidn is
a bit more debatable but I suspect that at least some people will view
it as bloat.  I would prefer to see the glibc packaging becoming less
rather than more monolithic and I think these two libraries would be
better placed in their own subpackages.

(Also, as an aside, this part of the patch doesn't seem to have anything
to do with the static libs and it should probably not be bundled into
the same changeset.)

p.

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

[Koen Kooi]

How about this one: 
http://dominion.thruhere.net/git/cgit.cgi/openembedded/commit/?h=koen/static-libs-rework&id=bfa6dd452da52a4516a712f288030c3571ed6c4c 
?

regards,

Koen

On 23-10-09 14:42, Phil Blundell wrote:
> On Fri, 2009-10-23 at 14:28 +0200, Koen Kooi wrote:
>> -libc_baselibs = "${base_libdir}/libcrypt*.so.*
>> ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.*
>> ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.*
>> ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so
>> ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so
>> ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so
>> ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so
>> ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so
>> ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so
>> ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so
>> ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so
>> ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so
>> ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so
>> ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so
>> ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
>> +libc_baselibs = "${base_libdir}/libcrypt*.so.*
>> ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.*
>> ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.*
>> ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so
>> ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so
>> ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so
>> ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so
>> ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so
>> ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so
>> ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so
>> ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so
>> ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so
>> ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so
>> ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so
>> ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so
>> ${base_libdir}/libcidn-*.so  ${base_libdir}/libmemusage.so"
>
> It took me a moment to spot what was actually happening here, but I
> think this is a step in the wrong direction.  Libmemusage is not
> something that most folks are going to want in their rootfs; libcidn is
> a bit more debatable but I suspect that at least some people will view
> it as bloat.  I would prefer to see the glibc packaging becoming less
> rather than more monolithic and I think these two libraries would be
> better placed in their own subpackages.
>
> (Also, as an aside, this part of the patch doesn't seem to have anything
> to do with the static libs and it should probably not be bundled into
> the same changeset.)
>
> p.

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

[Holger Hans Peter Freyther]

On Friday 23 October 2009 14:56:18 Koen Kooi wrote:
> How about this one:
> http://dominion.thruhere.net/git/cgit.cgi/openembedded/commit/?h=koen/stati
> c-libs-rework&id=bfa6dd452da52a4516a712f288030c3571ed6c4c ?

Could you push this as shared/static-libs-rework or tell me how to git clone 
your tree?

love
	z.

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

[Denys Dmytriyenko]

On Sat, Oct 24, 2009 at 04:32:54AM +0200, Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 14:56:18 Koen Kooi wrote:
> > How about this one:
> > http://dominion.thruhere.net/git/cgit.cgi/openembedded/commit/?h=koen/stati
> > c-libs-rework&id=bfa6dd452da52a4516a712f288030c3571ed6c4c ?
> 
> Could you push this as shared/static-libs-rework or tell me how to git clone 
> your tree?

http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=koen/static-libs-rework

-- 
Denys

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

[Koen Kooi]

On 24-10-09 04:32, Holger Hans Peter Freyther wrote:
> On Friday 23 October 2009 14:56:18 Koen Kooi wrote:
>> How about this one:
>> http://dominion.thruhere.net/git/cgit.cgi/openembedded/commit/?h=koen/stati
>> c-libs-rework&id=bfa6dd452da52a4516a712f288030c3571ed6c4c ?
>
> Could you push this as shared/static-libs-rework or tell me how to git clone
> your tree?

If you go to http://dominion.thruhere.net/git/cgit.cgi/openembedded/ 
there's a 'Clone' section at the bottom.

regards,

Koen

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

[Denys Dmytriyenko]

On Fri, Oct 23, 2009 at 01:42:12PM +0100, Phil Blundell wrote:
> On Fri, 2009-10-23 at 14:28 +0200, Koen Kooi wrote:
> > -libc_baselibs = "${base_libdir}/libcrypt*.so.* 
> > ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
> > ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
> > ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> > ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> > ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> > ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> > ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> > ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> > ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> > ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> > ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> > ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> > ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> > ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
> > +libc_baselibs = "${base_libdir}/libcrypt*.so.* 
> > ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
> > ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
> > ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> > ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> > ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> > ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> > ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> > ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> > ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> > ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> > ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> > ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> > ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> > ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so 
> > ${base_libdir}/libcidn-*.so  ${base_libdir}/libmemusage.so"
> 
> It took me a moment to spot what was actually happening here, but I
> think this is a step in the wrong direction.  Libmemusage is not
> something that most folks are going to want in their rootfs; libcidn is
> a bit more debatable but I suspect that at least some people will view
> it as bloat.  I would prefer to see the glibc packaging becoming less
> rather than more monolithic and I think these two libraries would be
> better placed in their own subpackages.

Phil,

I don't understand your concern here - packaging all the libraries from glibc 
does not mean they will appear in the rootfs. But having them handy as IPKs is 
helpful, when someone wants to do debugging - just opkg install those...

-- 
Denys

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

[Phil Blundell]

On Fri, 2009-10-23 at 14:21 -0400, Denys Dmytriyenko wrote:
> On Fri, Oct 23, 2009 at 01:42:12PM +0100, Phil Blundell wrote:
> > On Fri, 2009-10-23 at 14:28 +0200, Koen Kooi wrote:
> > > -libc_baselibs = "${base_libdir}/libcrypt*.so.* 
> > > ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
> > > ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
> > > ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> > > ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> > > ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> > > ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> > > ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> > > ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> > > ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> > > ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> > > ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> > > ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> > > ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> > > ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
> > > +libc_baselibs = "${base_libdir}/libcrypt*.so.* 
> > > ${base_libdir}/libcrypt-*.so ${base_libdir}/libc*.so.* 
> > > ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* 
> > > ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so 
> > > ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so 
> > > ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so 
> > > ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so 
> > > ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so 
> > > ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so 
> > > ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so 
> > > ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so 
> > > ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so 
> > > ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so 
> > > ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so 
> > > ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so 
> > > ${base_libdir}/libcidn-*.so  ${base_libdir}/libmemusage.so"
> > 
> > It took me a moment to spot what was actually happening here, but I
> > think this is a step in the wrong direction.  Libmemusage is not
> > something that most folks are going to want in their rootfs; libcidn is
> > a bit more debatable but I suspect that at least some people will view
> > it as bloat.  I would prefer to see the glibc packaging becoming less
> > rather than more monolithic and I think these two libraries would be
> > better placed in their own subpackages.
> 
> Phil,
> 
> I don't understand your concern here - packaging all the libraries from glibc 
> does not mean they will appear in the rootfs. But having them handy as IPKs is 
> helpful, when someone wants to do debugging - just opkg install those...

Everything in ${libc_baselibs} goes into the libc6.ipk output package,
so there's no practical way for users to avoid installing those
libraries.

p.

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

[Khem Raj]

On Fri, Oct 23, 2009 at 2:14 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 23-10-09 10:36, Phil Blundell wrote:
>>
>> On Fri, 2009-10-23 at 10:23 +0200, Holger Hans Peter Freyther wrote:
>>>
>>> One thing that pops back into my mind is to move .a files into a -static
>>> package? People that want to link statically can pick their .a files.
>>
>> Yes, I think someone else proposed this a few weeks ago but it doesn't
>> seem to have happened.  Given that static linking is pretty much a
>> minority pursuit nowadays (excepting libc_noshared.a) this sounds like a
>> fine idea.
>>
>> Stripping .a files with the default options will effectively destroy
>> them so the current state of affairs is definitely silly.  If you are
>> going to do that then you might as well just delete the files: they are
>> no use for anything after stripping.
>>
>> An alternative (or an addition) to the -static packaging would be to
>> arrange for .a files (and .o files, I guess) to be stripped with "strip
>> --strip-debug" (or perhaps --strip-unneeded).  This should leave enough
>> symbol data in the files for them to remain usable.
>
> Something like this (but without the mailer induced linewrapping)?
>
> diff --git a/classes/package.bbclass b/classes/package.bbclass
> index 046351a..2bf55e3 100644
> --- a/classes/package.bbclass
> +++ b/classes/package.bbclass
> @@ -183,6 +183,9 @@ def runstrip(file, d):
>         extraflags = "--remove-section=.comment --remove-section=.note
> --strip-unneeded"
>     elif "shared" in result or "executable" in result:
>         extraflags = "--remove-section=.comment --remove-section=.note"
> +       elif file.endswith(".a")::
> +                extraflags = "--remove-section=.comment --strip-debug"
> +

if you strip out anything from .a files it wont be recoverable. iow it
will be thrown away
in this case the debug information will be stripped out and when you
use these libraries
to link on target they wont have debug information. If thats a ok
tradeoff for size vs debuggability
then its ok.

>
>     bb.mkdirhier(os.path.join(os.path.dirname(file), ".debug"))
>     debugfile=os.path.join(os.path.dirname(file), ".debug",
> os.path.basename(file))
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index 7426095..6c1cc06 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -207,7 +207,7 @@ SOLIBSDEV_darwin = ".dylib"
>  SOLIBSDEV_darwin8 = ".dylib"
>  SOLIBSDEV_darwin9 = ".dylib"
>
> -PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-locale"
> +PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-static ${PN}-dev ${PN}-locale"
>  #enable this when bitbake is upgraded to cope with ++ values in the field
>  PACKAGES_DYNAMIC = "${PN}-locale-*"
>  FILES = ""
> @@ -225,9 +225,11 @@ FILES_${PN}-doc = "${docdir} ${mandir} ${infodir}
> ${datadir}/gtk-doc \
>             ${datadir}/gnome/help"
>  SECTION_${PN}-doc = "doc"
>
> +FILES_${PN}-static = "${libdir}/*.a ${base_libdir}/*.a"
> +
>  FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la
> \
> -                ${libdir}/*.a ${libdir}/*.o ${libdir}/pkgconfig \
> -                ${base_libdir}/*.a ${base_libdir}/*.o ${datadir}/aclocal
> ${datadir}/pkgconfig"
> +                ${libdir}/*.o ${libdir}/pkgconfig \
> +                ${base_libdir}/*.o ${datadir}/aclocal ${datadir}/pkgconfig"
>  SECTION_${PN}-dev = "devel"
>  ALLOW_EMPTY_${PN}-dev = "1"
>  RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPV})"
>
>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Denys Dmytriyenko]

On Fri, Oct 23, 2009 at 09:36:16AM +0100, Phil Blundell wrote:
> On Fri, 2009-10-23 at 10:23 +0200, Holger Hans Peter Freyther wrote:
> > One thing that pops back into my mind is to move .a files into a -static 
> > package? People that want to link statically can pick their .a files.
> 
> Yes, I think someone else proposed this a few weeks ago but it doesn't
> seem to have happened.  Given that static linking is pretty much a
> minority pursuit nowadays (excepting libc_noshared.a) this sounds like a
> fine idea.

I was the one who brought this up few weeks ago - but unfortunately I couldn't 
find enough time to invest in the solution of moving .a files into -static 
subpackages. I ended up just using Koen's fix for now, which worked for the 
external toolchain, as there are no _nonshared libs there...

-- 
Denys

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

[Koen Kooi]

On 23-10-09 05:04, Holger Hans Peter Freyther wrote:
> Hey Koen, All,
>
> I would like to revert:
> 	8fec15f70dcd0a8543b0af3ec256bf9cd108281e
> 	98a7d32826bc362c4ee434e7a4def7c852e75281
>
> The reason is that:
> 	This commit has introduced several breakages including
> 	stripping libc_nonshared.a breaking the gcc in the SDK and
>          for the device.
>          It has created build errors in meta-toolchain for binutils, gdb
>          see my illfated patch...
>
> I don't think we need to strip .a files as they will not end on the device
> and people will link their binaries to them and we will strip the binaries.

No real discussion on this the past few days, so I pushed my branch into 
.dev that basically boils down to a revert and fixes the issues raised 
by Phil.

regards,

Koen

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

[Phil Blundell]

On Tue, 2009-10-27 at 10:38 +0100, Koen Kooi wrote:
> No real discussion on this the past few days, so I pushed my branch into 
> .dev that basically boils down to a revert and fixes the issues raised 
> by Phil.

That sounds good to me.  If there are any remaining issues then
presumably we can fix them incrementally.

p.

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

[Koen Kooi]

On 27-10-09 11:21, Phil Blundell wrote:
> On Tue, 2009-10-27 at 10:38 +0100, Koen Kooi wrote:
>> No real discussion on this the past few days, so I pushed my branch into
>> .dev that basically boils down to a revert and fixes the issues raised
>> by Phil.
>
> That sounds good to me.  If there are any remaining issues then
> presumably we can fix them incrementally.

That's the plan :)

regards,

Koen

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

[Holger Hans Peter Freyther]

On Tuesday 27 October 2009 10:38:34 Koen Kooi wrote:

> No real discussion on this the past few days, so I pushed my branch into
> .dev that basically boils down to a revert and fixes the issues raised
> by Phil.

Thanks a lot. What do you think is still missing? I will revert my binutils-
cross-sdk commit. Is your storage problem with the .a files resolved too?

z.

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

[Koen Kooi]

On 27-10-09 11:50, Holger Hans Peter Freyther wrote:
> On Tuesday 27 October 2009 10:38:34 Koen Kooi wrote:
>
>> No real discussion on this the past few days, so I pushed my branch into
>> .dev that basically boils down to a revert and fixes the issues raised
>> by Phil.
>
> Thanks a lot. What do you think is still missing?

A check of all output packages for all recipes in OE :)

> I will revert my binutils-
> cross-sdk commit. Is your storage problem with the .a files resolved too?

It largely is now, for the remaining bits changes can be done incrementally.

regards,

Koen