Date: Sat, 06 Jan 1996 08:32:15 -0800 From: John Polstra <jdp@polstra.com> To: Doug Rabson <dfr@render.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: <199601061632.IAA09570@austin.polstra.com> In-Reply-To: Your message of "Sat, 06 Jan 1996 11:53:27 GMT." <Pine.BSF.3.91.960106115114.482D-100000@minnow.render.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601061632.IAA09570>