On Tue, Jan 05, 1999 at 11:45:00AM +0200, Polacco Fabrizio (NTC/He) wrote:
> That was an heritage of proprietary libraries, where this was the _only_
> debug you could do on it.
> You obviously can use a -dbg package to do also this, but it is not limited
> to this use.
I loked into libdb2-dbg (just curious) and I liked the approach used there
very much. It installs the library sources under /usr/src and the
debugging-libraries under /usr/lib/debug/. All you have to do to debug a
program using that library is to set LD_LIBRARY_PATH to /usr/lib/debug so the
debugging library gets used.
> There were several discussions about this on debian-policy, and discussion
> didn't came to a conclusion (so nothing was mandated, but nothing was
> forbitten).
> Later I hadn't time to restart it.
I think we have to get this things straightened out. If every Debian developer
has to think about this things again we just waste his time.
> At that time libc was semi-orphaned and changed hands a couple of times.
> Maybe the new maintainer ...
I think we have to agree on some guidelines first.
> But anyway, the idea that I should grab the sources and rebuild a library is
> not a good offer for a system that pretends to be mainly dedicated to
> development.
Right.
> Having full functionality -dbg packages doesn't hurt those that wants simply
> to trace their programs, while the contrary can hurt a lot.
>
> I had a problem with man crashing on circular links (it should still be
> there), and I had to buy a new disk to rebuild libc6 to run gdb on it and
> find the exact line of code where the bug was.
> I would have really appreciated a full functional -dbg package (maybe split
> in two or more parts, because of the size) that would offer me instant
> debugging.
I don't think splitting would be good.
> fab
cu
Torsten
Attachment:
pgpYRJ7y4MfSs.pgp
Description: PGP signature