[RFC] -dbg for static libraries?

[RFC] -dbg for static libraries?

[Denys Dmytriyenko]

As target binaries and libraries are now built with extra debugging symbols, 
some of the -dbg packages are very large. Unfortunately, -dbg packages only 
contain debug versions of executable binaries and shared libraries, but not 
static libraries, which go directly into -dev packages. That increases the 
size of sdk/toolchain tarballs, which include -dev packages, depending on the 
main packages, and end up with stripped shared libs, but bloated static libs.

I understand, that -dev packages are specifically for development and having 
full debugging symbols in a library might be helpful for that, but -dev 
packages don't usually depend on -dbg, and most toolchain-target tasks don't 
include them either, hence not providing debugging versions of shared libs in 
the sdk/toolchain.

Would it make sense to package stripped version of a static lib into -dev and 
the full version into corresponding -dbg?

-- 
Denys

Re: [RFC] -dbg for static libraries?

[Koen Kooi]

On 17-09-09 07:40, Denys Dmytriyenko wrote:
> As target binaries and libraries are now built with extra debugging symbols,
> some of the -dbg packages are very large. Unfortunately, -dbg packages only
> contain debug versions of executable binaries and shared libraries, but not
> static libraries, which go directly into -dev packages. That increases the
> size of sdk/toolchain tarballs, which include -dev packages, depending on the
> main packages, and end up with stripped shared libs, but bloated static libs.
>
> I understand, that -dev packages are specifically for development and having
> full debugging symbols in a library might be helpful for that, but -dev
> packages don't usually depend on -dbg, and most toolchain-target tasks don't
> include them either, hence not providing debugging versions of shared libs in
> the sdk/toolchain.
>
> Would it make sense to package stripped version of a static lib into -dev and
> the full version into corresponding -dbg?

What about the stripped version in -dev and the corresponding symbols in 
-dbg?

regards,

Koen

Re: [RFC] -dbg for static libraries?

[Stanislav Brabec]

Koen Kooi wrote:
> > Would it make sense to package stripped version of a static lib into -dev and
> > the full version into corresponding -dbg?
> 
> What about the stripped version in -dev and the corresponding symbols in 
> -dbg?

Or:

1. Disable static by default. Static libraries are rarely needed.
Recipes (or distros) that want static libraries must explicitly enable
it.


2. What about -dev, -dbg, -static and -static-dbg? I have tens of .a
files installed on my microdrive, because .so* are sufficient.

Four sub-packages may sound as a overkill, but I don't think so. Static
counterparts of shared libraries are really very rarely needed.

It would need to improve the splitting logic a bit, but it is still
possible to automatize it:

- libfoo.so was installed -> libfoo.a should go to -static and dbg to
-static-dbg.

- libfoo.a was installed alone -> libfoo.a should go to -static and dbg
to -static-dbg.

- very few packages need to be handled individually (e. g. glibc,
packages that install libfoo_pic.a etc.)

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

Re: [RFC] -dbg for static libraries?

[Phil Blundell]

On Thu, 2009-09-17 at 01:40 -0400, Denys Dmytriyenko wrote:
> Would it make sense to package stripped version of a static lib into -dev and 
> the full version into corresponding -dbg?

I'm not sure that you'd want the debugging .a file in -dbg itself, since
the -dbg packages are for installation on the target device and the .a
libraries would be useless there. 

Punting the debug versions of the .a libraries into a new package
(-static-dbg or some such) wouldn't be a bad idea.  Or, for SDK
purposes, you could even consider ditching the .a libraries altogether
for packages that have a .so since virtually nobody is going to be doing
static linking in this day and age.

p.

Re: [RFC] -dbg for static libraries?

[GNUtoo]

On Thu, 2009-09-17 at 13:01 +0100, Phil Blundell wrote:
> On Thu, 2009-09-17 at 01:40 -0400, Denys Dmytriyenko wrote:
> > Would it make sense to package stripped version of a static lib into -dev and 
> > the full version into corresponding -dbg?
> 
> I'm not sure that you'd want the debugging .a file in -dbg itself, since
> the -dbg packages are for installation on the target device and the .a
> libraries would be useless there. 
> 
> Punting the debug versions of the .a libraries into a new package
> (-static-dbg or some such) wouldn't be a bad idea.  Or, for SDK
> purposes, you could even consider ditching the .a libraries altogether
> for packages that have a .so since virtually nobody is going to be doing
> static linking in this day and age.
I often do static linking for different reasons:
*different libc on the target(like with android for instance)
*debugging(like in the case where all shared libs segfaulted on mips
+uclibc,I needed a static gdb,a static strace etc...)
Denis

Re: [RFC] -dbg for static libraries?

[Phil Blundell]

On Sat, 2009-09-19 at 23:48 +0200, GNUtoo wrote:
> Phil Blundell wrote:
> > Or, for SDK purposes, you could even consider ditching the .a
> > libraries altogether for packages that have a .so since virtually
> > nobody is going to be doing static linking in this day and age.
>
> I often do static linking for different reasons:
> *different libc on the target(like with android for instance)
> *debugging(like in the case where all shared libs segfaulted on mips
> +uclibc,I needed a static gdb,a static strace etc...)

Neither of those are really the kind of use-cases that the SDK is
targeting.  If you are doing initial bringup/debug on a particular
target system then you would probably want to use an in-tree build just
as you do today.  

The SDK exists to support casual software development on relatively
stable target platforms, by people who don't wish to build the entire
system from scratch for themselves, and in almost all cases you don't
want to encourage static linking there.

p.

Re: [RFC] -dbg for static libraries?

[GNUtoo]

On Sun, 2009-09-20 at 08:13 +0100, Phil Blundell wrote:
> On Sat, 2009-09-19 at 23:48 +0200, GNUtoo wrote:
> > Phil Blundell wrote:
> > > Or, for SDK purposes, you could even consider ditching the .a
> > > libraries altogether for packages that have a .so since virtually
> > > nobody is going to be doing static linking in this day and age.
> >
> > I often do static linking for different reasons:
> > *different libc on the target(like with android for instance)
> > *debugging(like in the case where all shared libs segfaulted on mips
> > +uclibc,I needed a static gdb,a static strace etc...)
> 
> Neither of those are really the kind of use-cases that the SDK is
> targeting.  If you are doing initial bringup/debug on a particular
> target system then you would probably want to use an in-tree build just
> as you do today.  
> 
> The SDK exists to support casual software development on relatively
> stable target platforms, by people who don't wish to build the entire
> system from scratch for themselves, and in almost all cases you don't
> want to encourage static linking there.
> 
> p.
ok thanks for the explanations...I think I have read too fast(lots of
mails) (I was thinking that the static libraries were to be removed in
the normal in-tree build)
Denis.