Re: RFC: Debugging libraries
On Wed, Apr 28, 1999 at 10:25:26PM +0100, EXT Steve Haslam wrote:
> On Tue, Apr 27, 1999 at 05:45:22PM +0300, Fabrizio Polacco wrote:
> 129 remaining, totalling 1209096 bytes (13%)
> ... but that's still 41% of gnome-libs and 25% of gnome-core that has
> to be duplicated for *every* binary upload. I'd rather not.
Well, it is quite clear that putting part of the sources into the
lib*-dbg packages will increase the size of the distribution, but I
don't like this argument. Our goal is to make a service for users, not
to make life easier for ftp site and CD sellers, at least not at the
expense of the users.
Programmers are our users (and the best ones IMHO), and servicing them
is our goal.
And this is the exact reason why we ship archive libraries too (both in
-dev and in -dbg pkgs): because users linking to commercial libs shipped
only as static libs need them! Think of this: these libs are surely
non-free; well we ship tons of archive libs only because of that.
I would say that this -dbg service is even more important.
Said that I would like to say that what I mostly dislike of the idea of
using the source package to debug a lib (or a pgm using the lib) is that
some libs have huge sources: glib and X are two examples, and maybe
others. These sources generates tens of different libs packages and I
prefere the idea to install the sources of what exactly I need, not the
full big source, apply a huge patch, maybe run a big configure ...
I had to do this when I traced the libc bug for the circular symlinks,
and it was a great pain. Comparing with the fact that I did it using
program man, which links to libdb2 (whose -dbg packages are created
following my way), the difference of use in debugging was so
incredible that I had no dubt that that was the Right-Way[tm].
> > gdb will present you the wrong source line.
> > More, some tarball carry general routines to be used in case they are
> > missing on the compilation system, which is different than the one we
> > run the dbg lib.
> I'm not quite sure I follow this. If the debian/rules file is
> well-written, it is easy to reproduce the process of getting the
> sources into the same state as they were on the original build system,
> surely? configure does not modify source files: it may create a
> config.h, but it doesn't modify anything (if it did, you couldn't
> configure away from the source directory).
Well , if this was true then this would mean that I was quite
unfortunate, as both the programs I mentioned has configure stages that
does more that config.h .
I ended including sources in the -dbg pkg because i noticed that dbg was
showing me the wrong source line even if I was working on the same
machine on which the library was packaged (there were a clean stage in
the middle). And if I had rerun configure I would have had the problem
of ... what options to give it? That rules file runs configure twice!
I was really thinking of offering debug-out-of-the-box and taking a
snapshot of the sources _after_ the compilation of the -dbg package
achive exactly this.
If the dimension of the distribution is a problem then ... let's put
all -dev and -dbg packages on a separate CD.
| firstname.lastname@example.org email@example.com firstname.lastname@example.org
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
| email@example.com gsm: +358 (0)40 707 2468