Re: PW#5-11: Policy on stripping static libraries
> > -dev: Only headers, and the ".so -> .so.minor" symlink
> > -dbg: Eighter static or shared (need to discuss this probably, maybe both)
> > libs with debugging info.
> >
> > This proposal is very different from what we have now, and we really should
> > discus this before this becomes policy.
>
> Humm, it seems to me that we have a lot of libraries following this
> "policy", and I'm sure I have seen something on the policy docs, ...
Are you sure? All I remember is that the -dev packages should have
the static libraries in them, according to the docs. What libraries
do we currently have that have -dev packages that follow the above?
> I also think that static libs maybe aren't needed anymore, but I am
> more reluctant to forbit them. Maybe someone could have a good reason
> to ask for them (maybe security reasons?)
Sometimes one hears people say they need static binaries for security
reasons, but these people usually don't seem to understand that they
have to recompile _every_ such binary the moment a libc bug is discovered
and fixed. Most security people seem to agree that security-wise it's
better to have shared binaries.
> I don't know, maybe we can
> say in the policy that if someone has a good reason to ask for a static
> lib in some package he simply has to explain and if the reeason is
> valid the maintainer can add a -static package ...
>
>
> >> >> * 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?
> >>
> >> There is no need to force all users on a system to load a debug library
> >> which is really needed only from _one_ user.
> >
> > Please, note that the debugging info is _not_ used/loaded/whatever
> > if you don't do debugging. Running a programme while using the libs
> > with debugging info is (as far as I'm aware) excactly as fast, and
> > uses excactly as much system ram as using the libs without the
> > debugging info.
>
> I remember having read your expalnation about speed of those libs, but,
> please, reread this quote.
What quote are you refering to?
> If the libs are compiled with -DDEBUG
They aren't.
> (as I would really ask from a -dbg package) the code will probably have
> debugging prints conditioned on that define, and this code shouldn't be
> run as "runtime" on a production environment.
Is that your only argument agianst putting the lib in /etc/ld.so.conf?
If so, then I think you'll fail to convince me...
>
>
>
> > So, the only difference with your proposal:
> >
> >> every time you want to use the debug libraries, just do
> >>
> >> LD_LIBRARY_PATH=/usr/lib/debug gdb <prog>
> >
> > Is that in your case whenever someones starts debugging, those
> > debugging libraries (code+symbols) are loaded a second time in
> > memory, whereas in mycase the code always is only once in memory.
>
> Well, actually those programs are statically linked, so we have anyway
> a big advantage.
I'm only talking about dynamically linked programmes. Where do you
see statically linked programmes?
> And a debugging session isn't something that a lot of
> users do all the time, so a doubled library is not so bad.
> And I'm not really sure that gdb uses the lib already in memory and
> doesn't reload it again ...
I'm more-or-less certain gdb simply reloads the libs in memory with mmap.
Thus they will only be in memory once.
> Anyway, you have not finished to comment on my proposal: what about
> having the source?
I'd like that, althought that would require all libraries to be
re-build again. But for an "optional" policy I'd like it.
One thing though: doesn't this require the source to be located
in the same place during the building of the debugging library as
it will be on the user-system? If so, that will make the building
of the library one step more difficult (you'll not be able to build
it from your homedir any more).
--
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: