Date: Tue, 25 Apr 1995 15:49:33 -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: <199504252149.PAA13343@trout.sri.MT.net> In-Reply-To: terry@cs.weber.edu (Terry Lambert) "Re: Shlib complaints ( was Re: benchmark hell..)" (Apr 25, 3:22pm)
next 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. Sort of. We aren't losing binary compatability as the tools themselves haven't become incompatible, but we do have to provide the older libgcc shlib since libgcc is no longer used. As far as versioning goes, there have been no rules broken since the versioning problems only occur with shlibs, and the backwards compatability issue is caused from making libraries non-shared. > > > 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%). Whoa. Did you read what I read? My question was (in more obvious wording) "Would linking a program static using a static library made up of PIC compiled objects cause run-time penalties" There are no run-time linking issues involved whatsoever, since we are linking the program statically. Basically, my question boils down to the differences between PIC objects and non-PIC objects. > 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. You could still differentiate between shared/static libraries, although I could understand where that would be un-necessary since the libraries would be essentially identical. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504252149.PAA13343>