From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: cgf-use-the-mailinglist-please@sourceware.org
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Add expat to the GDB sources
Date: Mon, 24 Jul 2006 22:29:00 -0000 [thread overview]
Message-ID: <200607242229.k6OMTR1a022831@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20060724214157.GC25632@trixie.casa.cgf.cx> (message from Christopher Faylor on Mon, 24 Jul 2006 17:41:57 -0400)
> Date: Mon, 24 Jul 2006 17:41:57 -0400
> From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
>
> Also, we're not talking about having to track down scores of packages,
> we're talking about *one* package. If we actually were talking about
> adding about more packages it would actually make less sense to do
> something like this. 'src' would be bloated and we'd be in constant
> package update mode.
Therefore we should not add random features to GDB that require more
"external" packages.
> It sounds like you're advocating that every project which relies on
> external libraries should include the source code for those libraries.
> If that is the case, it means that we shouldn't bother with shared
> libraries at all. Every package would, instead, be bloated by the
> inclusion of its own version of expat, and openssl, and libtiff, etc.
Shared libraries are hard. You can only do it right if you correctly
implement a version policy, which is almost impossible to do if you
don't have some sort of central control. It really is only worth
doing if there are more than a handlful of different programs using
the same library that are likely to be used simultaniously.
> >In other words, when I download a package, I want it ideally to build
> >out of the box, period.
>
> IMO, that is an unrealistic expectation.
But one that is true for the current GDB on many systems right now.
> >No questions asked, and no additional prerequisites that could turn a
> >simple build job into an agony that lasts the better part of my day,
> >because each prerequisite package needs a bit of tweaking to build and
> >install properly. By contrast, when I get readline etc. with GDB, I
> >can be _certain_ that someone already tried and succeeded to build
> >_this_ version of the library with _this_ configury and _this_ GDB
> >release.
>
> And, if you are on linux or windows, you can be certain that your
> version of gdb has a different version of readline than every other
> package on the system and that gdb is slightly bigger and possibly
> slightly incompatible as a result. I hate this about insight, also.
> The problem is even worse there. That is a standard problem with
> including disparate versions of libraries.
A properly engineered Linux distribution solves this by building
everything, including gdb, with a properly chosen version of readline,
and testing this setup extensively. When a user isn't satisfied with the
> But, where does this philosophy end? Are you *really* advocating that
> every shipping package should include the source code of any libraries
> that they use? So gdb should also include ncurses?
The philosophy has always been that one should be able to build a GNU
toolchain without any external dependencies, to be able to bootstrap
into a situation wher you can use the toolchain to build other Free
Software.
next prev parent reply other threads:[~2006-07-24 22:29 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-18 13:40 Daniel Jacobowitz
2006-07-18 13:57 ` Daniel Jacobowitz
2006-07-21 0:35 ` Joel Brobecker
2006-07-21 0:39 ` Daniel Jacobowitz
2006-07-21 0:45 ` Joel Brobecker
2006-07-23 21:52 ` Mark Kettenis
2006-07-23 22:03 ` Daniel Jacobowitz
2006-07-23 22:40 ` Christopher Faylor
2006-07-23 22:57 ` Daniel Jacobowitz
2006-07-23 23:13 ` Christopher Faylor
2006-07-24 0:17 ` Daniel Jacobowitz
2006-07-23 23:15 ` Pedro Alves
2006-07-23 23:18 ` Mark Kettenis
2006-07-24 0:15 ` Daniel Jacobowitz
2006-07-24 6:20 ` Joel Brobecker
2006-07-24 15:30 ` Christopher Faylor
2006-07-24 15:50 ` Daniel Jacobowitz
2006-07-24 16:37 ` Christopher Faylor
2006-07-24 21:58 ` Mark Kettenis
2006-07-24 19:50 ` Eli Zaretskii
2006-07-24 19:52 ` Daniel Jacobowitz
2006-07-24 20:29 ` Eli Zaretskii
2006-07-24 20:36 ` Daniel Jacobowitz
2006-07-24 15:24 ` Christopher Faylor
2006-07-24 19:47 ` Eli Zaretskii
2006-07-24 19:51 ` Daniel Jacobowitz
2006-07-24 20:22 ` Christopher Faylor
2006-07-24 20:29 ` Eli Zaretskii
2006-07-24 20:43 ` Daniel Jacobowitz
2006-07-24 21:42 ` Christopher Faylor
2006-07-24 22:18 ` DJ Delorie
2006-07-24 22:29 ` Mark Kettenis [this message]
2006-07-24 22:34 ` Daniel Jacobowitz
2006-07-24 22:37 ` Daniel Jacobowitz
2006-07-25 0:36 ` Christopher Faylor
2006-07-24 22:49 ` Mark Kettenis
2006-07-24 23:41 ` Daniel Jacobowitz
2006-07-25 0:47 ` Christopher Faylor
2006-07-31 17:33 ` Daniel Jacobowitz
2006-07-31 20:24 ` Daniel Jacobowitz
2006-07-31 20:39 ` Christopher Faylor
2006-07-31 21:33 ` Mark Kettenis
2006-08-01 0:42 ` Daniel Jacobowitz
2006-08-01 1:01 ` Daniel Jacobowitz
2006-07-24 22:08 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200607242229.k6OMTR1a022831@elgar.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=cgf-use-the-mailinglist-please@sourceware.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox