From owner-freebsd-hackers Tue Apr 25 14:29:18 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA18908 for hackers-outgoing; Tue, 25 Apr 1995 14:29:18 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA18892 for ; Tue, 25 Apr 1995 14:29:14 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA01834; Tue, 25 Apr 95 15:22:39 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504252122.AA01834@cs.weber.edu> Subject: Re: Shlib complaints ( was Re: benchmark hell..) To: nate@trout.sri.MT.net (Nate Williams) Date: Tue, 25 Apr 95 15:22:39 MDT Cc: hackers@FreeBSD.org In-Reply-To: <199504252055.OAA13105@trout.sri.MT.net> from "Nate Williams" at Apr 25, 95 02:55:42 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > 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. Some of this is already being sacraficed with the new tool set (which is why there's a backward compatability library for the gcc stuff that itself breaks several "rules" on versioning, etc. > > 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? In order: Yes, I think they would be about 10% slower (there is some question as to whether the "10%" number was arrive at legitimately, or whether the actual number is smaller, and the "10%" is an inflated value because the benchmarks didn't take into account the average time a program would be running (making the dynamic link overhead a significant fraction of the resulting benchmark run time -- say 10%). The current linker would work fine. The big change would be the moving of the internal synbol table (the one you can't strip) into being generated in the ar instead of in the ld coelescing of the shared objects. There would be minor changes to the ld to recognize the resulting data-only object. The main issue I see in doing this is one of licensing -- it must be possible to generate static-only libraries so that you can continue to produce statically linked Motif binaries, for instance. Hopefully some work currently under way will obsolete this need by obsoleting OSF as a source for Motif libraries unless they change their licensing a bit. > 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. Yes. This is the big "rebuild the world" win in Linux, since it is still using staic locations for dynamic symbol resoloution ...the SVR3 model. This is about to change over there with ELF, though, and they will be using basically the same approach as BSD currently uses. Might be nice to stay one step ahead. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.