Date: Sat, 22 Nov 2003 12:38:41 -0500 From: Michael Edenfield <kutulu@kutulu.org> To: Tim Kientzle <kientzle@acm.org> Cc: freebsd-current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything Message-ID: <20031122173840.GD15294@wombat.localnet> In-Reply-To: <3FBEA209.20006@acm.org> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <20031118164905.R35009@pooker.samsco.home> <20031119141059.GA14308@madman.celabo.org> <20031119141950.GA95734@ussenterprise.ufp.org> <3FBEA209.20006@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Tim Kientzle <kientzle@acm.org> [031121 18:40]: > Leo Bicknell wrote: > >To boot a machine into single user mode you need a kernel, init, > >and /bin/sh (minimally). It would seem to me that alone is a good > >argument for those three things to be static. > * Rewrite dlopen() to not require dynamic linking. >=20 > There were some patches for this submitted at one point. > As I recall, the people who looked at them were not entirely > comfortable with them. (I'd be concerned about version > conflict problems with this approach: what happens when > a dynamically-loaded NSS module refers to a libc function? > Does that get resolved to the already statically-linked > version? Or does another copy of libc get dynamically linked > with potential version conflicts? Does anyone know?) >=20 > I personally think this is worth researching, though I > have my doubts. I took a look at the glibc implementation of dlopen() breifly, since that does function from within libc.a. It appears that you *do* get more than one loaded copy of libc. The copy of dlopen() that is built when #ifndef SHARED includes a flag: __libc_multiple_libcs that is set to 1. Additionally, I was reading comments from some of the glibc developers who basically claim that dlopen() in a static binary *only* works if you dlopen() a NSS module. It isn't guaranteed to work in the general case because the static binary has no DYNAMIC elf section to resolve external references etc. I suspect this means NSS modules are limited in what they are allowed to reference and still work? I haven't looked in much detail on their implementation but it certainly looks like a hack just to make NSS work, which I don't think is a good long-term solution. --Mike --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/v58gCczNhKRsh48RAgLCAJ9C/TIJ6cRTldlNNLj3n3ml0aimUwCgqwzf e0HG+k1+0IUq+SqurFA2QuQ= =DbPO -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031122173840.GD15294>