Re: PW#5-11: Policy on stripping static libraries
> On 14 Jan, joost witteveen wrote:
> >>
> >> Debian Policy Weekly issue #5 :
> >>
> >> runtime pkg: shared lib stripped with --strip-unneeded
> >> develop pkg: static lib stripped with --strip-debug
> >> debug pkg: static lib unstripped
> >
> > I may be _way_ wrong here, but it seems to me that most people that do
> > (real) development, also want to debug. So we could make the "debug pkg"
> > unneeded by just allowing the develop pkg to contain the debug info.
> > (Personally, I don't see much use for static libs without debug info).
>
> I absolutely object.
> People need to install -dev packages mostly because thay are compiling
> programs that link some library, and therefore they need the symlink
> lib.so -> lib.so.soname and some header files.
Then they don't need the statically linked libaries at all.
I don't object too much against what you say, it's just that
I don't see any reason to generate static libs without debugging info.
> People that wants to create a statically linked program need an archive
> library (humm, seems an assertion that needs to be re-checked; it's
> historically true, but ... who knows? I'll do some tests trying to
> build static executables from shared libs).
No, that will not work. Or at least result in sub-optimal code, as
the shared libs are compiled with -fPIC, whereas the static ones are
not. But how many people want to create statically linked programmes,
that don't want to do debugging?
As far as I see, more people want debugging than statically linked
programmes. But then again, not all people that want debugging
info in the libraries.
> Instead, the -dbg package, is required only from someone that is
> debugging a program linked with that lib, just in case he wants to
> debug the library itself, or simply follow/list the lib's flow (in these
> cases he also needs the sources).
Note that in the libg++ case, you also want the debugging info if you
only debug your own programme. Not just when you debug the libraries.
> Actually only your libg++ holds shared libs for debugging, (and
> installs them on top of /etc/ld.so.conf, which is IMO something not to
> be done on a production system :-)
Give me a way to do it better, and I'll adopt that. But I don't think
there is a better way. And I believe the approach I've taken has been
discussed with David Engel (tought I'm not sure any more).
>, while all the others (with two
> exeptions) have a static archive with a different name (from the one in
> the -dev package).
But I don't want to have to relink my executable just to be able to
debug it. That's why I also want debugging info in the shared libs.
> I have already proposed (well, I'm proposing it now :-) to build -dbg
> packages in a different way:
>
> * a shared unstripped lib, compiled with -DDEBUG, with the same
> name.soname of the runtime lib, installed in a different dir
> (/usr/lib/debug) which *ISN'T* in /etc/ld.so.conf
Why should this not be in ld.so.conf? What's your reasoning behind that?
Why would I want to install a libarary that I don't want to use?
--
joost witteveen, joostje@debian.org
Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).
Reply to: