From owner-freebsd-hackers  Tue Apr 25 13:51:30 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id NAA15678
          for hackers-outgoing; Tue, 25 Apr 1995 13:51:30 -0700
Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA15668
          for <hackers@FreeBSD.org>; Tue, 25 Apr 1995 13:51:23 -0700
Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.11) id OAA13105; Tue, 25 Apr 1995 14:55:42 -0600
Date: Tue, 25 Apr 1995 14:55:42 -0600
From: Nate Williams <nate@trout.sri.MT.net>
Message-Id: <199504252055.OAA13105@trout.sri.MT.net>
In-Reply-To: terry@cs.weber.edu (Terry Lambert)
       "Re: Shlib complaints ( was Re: benchmark hell..)" (Apr 25,  2:32pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: terry@cs.weber.edu (Terry Lambert)
Subject: Re: Shlib complaints ( was Re: benchmark hell..)
Cc: hackers@FreeBSD.org
Sender: hackers-owner@FreeBSD.org
Precedence: bulk


> I think we are in violent agreement that there should not be specification
> of the exported interfaces to reduce the overall symbol space.

Wow, an agreement on the mailing list?  Quick call a reporter.

> On the other hand, I believe the problem being pointed at is a real one.
> 
> And I think it is solvable without restricting the symbol exports.

Again, we are in agreement.

> The issue that is being argued is twofold:
> 
> 1)	The symbol space in the static symbol resoloution table in
> 	a shared binary is large, so it takes a while to search and
> 	is thus "slow".

Correct.

> 2)	There is pollution of the name space by symbols being required
> 	because they are being referenced, and this is in turn the
> 	result of the libraries being linked as a monoblock instead
> 	of as individual objects (some of which could be omitted).
> 
> Now, linking as individual objects would relieve both problems.

Correct, but it would mean that we would lose binary compatability with 
older FreeBSD releases and with NetBSD, unless we could add a global
loader which recognizes how a program was linked via some a.out magic.

This is a non-trivial issue.

> There is a question of "what is a shared library" and "PIC code is more
> expensive".  I would propose resolving the library problem by making
> PIC the default code type for regular libraries; this would mean that
> it was impossible to to produce a library which could not then be
> processed into a shared library.

That would be an easy thing to do.  Would linking programs statically
against PIC compiled libraries affect them at run-time any though?  Would
it require a special linker, or mods to the current linkder?

This would make building libraries much faster, since we only need to
build one object file (or two if profiled libraries are being built)
instead of two.


Nate