On Sun, May 20, 2007 at 09:19:52PM -0500, Steve Greenland wrote:
> On 20-May-07, 13:41 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote: 
> > On Wed, May 09, 2007 at 11:28:49AM -0500, Steve Greenland wrote:
> > > On 09-May-07, 04:02 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote: 
> > > > I'm not entirely sure about the specifics, and especially not across
> > > > architectures; but regardless, doing a PLT lookup is more expensive than
> > > > doing a function call to something that was statically linked in.
> > > 
> > > True. Now, does anyone have measurements to show that this has
> > > any actual significance in real world code on modern hardware?
> > 
> > I don't see why that would be relevant. We're not providing statically
> > linked binaries; we are providing static libraries so that people who
> > want them can perform static linking for their own in-house software.
> 
> Why should we spend time and space to provide something that doesn't
> do anything useful?[1]

I also once heard an argument that static libraries are easier to
maintain. While I disagreed at first, it started to make sense when it
was explained that in-house software in /usr/local which does not add
dependencies to the package management system easily breaks on upgrades.

If you really think dropping static libraries is the best way forward,
then I think you should make a case for it that also explains why we do
give our users all possible and impossible options by linking our
software against every library in sight, while at the same time not
providing them with the basic option of compiling their software
statically. Moreover, remember that most, if not all, other
distributions have it, meaning that newbie-oriented documentation
assumes it'll work, and that not providing it for no good reason will
probably only serve to annoy and confuse the user.

And that's said with my m68k buildd admin hat, uh, hmm. Let's say "right
next to me" (rather than "on").

-- 
Shaw's Principle:
        Build a system that even a fool can use, and only a fool will
        want to use it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to