Date: Sat, 6 Jan 1996 17:34:00 +0000 (GMT) From: Doug Rabson <dfr@render.com> To: John Polstra <jdp@polstra.com> Cc: hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Anyone got GNU `dld' ported to FreeBSD? Message-ID: <Pine.BSF.3.91.960106172600.482H-100000@minnow.render.com> In-Reply-To: <199601061632.IAA09570@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 Jan 1996, John Polstra wrote: > Doug Rabson wrote: > > > It would be pretty easy in a static binary to 'demand load' ld.so > > the first time a dl*() function was used, I think. > > There's more to it than that. For instance, any useful library that > you're going to want to demand-load will almost certainly depend on some > functions in libc. When you demand-load something into a dynamically > linked executable (which we currently support), the library you're > loading will use the shared version of libc.so.x.x that is already present > in the executable's address space. But if the executable is static, > there is no way to link something new to its embedded, statically-linked > libc. (If the executable has been stripped, then the necessary symbols > aren't even there.) Furthermore, of course, not all of the modules > from libc.a will even be present in the executable -- only those that > were seen as necessary when the executable was built. > > It might be tempting to simply load in a new, shared copy of > libc.so.x.x when you do the dlopen. But that also wouldn't work > properly. Libc is not just functions; it's _shared_ data, too. For > example, data structures in the stdio package keep track of which files > are open, which buffers have data in them, etc. It doesn't work well to > have two independent copies of that stuff lying around. I think the right thing to do would be to have ld create a complete struct _dynamic for the application, with symbol tables. When it initialises ld.so, it supplies this table. When the app dlopens an object depending on libc.so, libc is mapped as usual (since it is not already loaded) but all the symbol lookups for libc symbols which happen to be linked into the main application would use the app's version by the normal rules. The downside of this is a larger static executable due to the extra symbol tables. Maybe have 3 classes of app: dynamic static but can use dl*() static -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960106172600.482H-100000>