Date: Tue, 25 Apr 1995 13:32:02 -0600 From: Nate Williams <nate@trout.sri.MT.net> To: terry@cs.weber.edu (Terry Lambert) Cc: patl@asimov.lashley.slip.netcom.com, hackers@FreeBSD.org Subject: Re: Shlib complaints ( was Re: benchmark hell..) Message-ID: <199504251932.NAA12630@trout.sri.MT.net> In-Reply-To: terry@cs.weber.edu (Terry Lambert) "Re: Shlib complaints ( was Re: benchmark hell..)" (Apr 25, 1:11pm)
next in thread | raw e-mail | index | archive | help
> > [ only exporting specified symbols in shlibs ] > > > > 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. > > Not true; there is very little difference topologically between not > exporting more than you need to and not importing more than you need > to. The second case can be made automatic if the shared libs were not > monolithic .o files. There is a *large* difference between exporting symbols and importing symbols. You're trying to wedge two arguements together which don't belong together. 1) Exporting symbols in functions/libraries 2) Importing symbols from functions/libraries The current setup of exporting functions is adequate w/out having to add the extra overhead of asking the developer to specify which symbols are to be seen. However, because of the current scheme which concatenates all of the objects together into one big object file, we have difficulties doing symbol resolution at run-time. These are completely different problems and should be treated differently. > > > 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. > > It's worth it for the C++ curses problems and it's worth it for unused > virtual bas classes from a c++ library. > > It's also worth it in the reduction of available symbol space. Let's see the code to implement this. Now that your legal hassles are out of the way, I'd *really* like to see code solutions instead of paper tigers from you. :-) C'mon Terry, you've been promising this stuff for *years*!!! Let's see some bits so we can believe that all of this talk has some basis in reality. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504251932.NAA12630>