Date: Tue, 25 Apr 1995 14:55:42 -0600 From: Nate Williams <nate@trout.sri.MT.net> To: terry@cs.weber.edu (Terry Lambert) Cc: hackers@FreeBSD.org Subject: Re: Shlib complaints ( was Re: benchmark hell..) 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)
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504252055.OAA13105>