Date: Tue, 25 Apr 95 15:22:39 MDT From: terry@cs.weber.edu (Terry Lambert) To: nate@trout.sri.MT.net (Nate Williams) Cc: hackers@FreeBSD.org Subject: Re: Shlib complaints ( was Re: benchmark hell..) Message-ID: <9504252122.AA01834@cs.weber.edu> In-Reply-To: <199504252055.OAA13105@trout.sri.MT.net> from "Nate Williams" at Apr 25, 95 02:55:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504252122.AA01834>