From owner-freebsd-hackers Tue Apr 25 10:36:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02622 for hackers-outgoing; Tue, 25 Apr 1995 10:36:17 -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 KAA02608 for ; Tue, 25 Apr 1995 10:36:12 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.11) id LAA12140; Tue, 25 Apr 1995 11:40:10 -0600 Date: Tue, 25 Apr 1995 11:40:10 -0600 From: Nate Williams Message-Id: <199504251740.LAA12140@trout.sri.MT.net> In-Reply-To: terry@cs.weber.edu (Terry Lambert) "Re: benchmark hell.." (Apr 25, 11:19am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: terry@cs.weber.edu (Terry Lambert), patl@asimov.lashley.slip.netcom.com Subject: Shlib complaints ( was Re: benchmark hell..) Cc: hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk [ only exporting specified symbols in shlibs ] > Clearly, this would also resolve the problem of "curses" with the > C++ libraries. The problem with this is that we are now placing a migh bigger load on the developer to specify which symbols to be exported, rather than having the compiler do it with judicious use of static and extern as it is currently. > The problem in the current implementation that prevents this is that > the link does not "run to completion" as it would with a normal library > archive; that is, instead of dragging in only the externally referenced > code from the shared lib as linked dynamic symbols and then dragging in > only the library data referenced by the code in the program and the code > previously dragged in, all data and all code are dragged in. This is a problem in the current implementation, but Paul's intention was to mimic Sun-style shlibs, which he has done pretty well. > This is an inevitable result of not using an archive format for the > shared library objects so they can be pulled in an object at a time (or > not), which is what you do with normal library archives. This would solve some of the problems I've been trying to work out, but it would mean a re-write of most of the code, which is IMHO not worth it. Nate