Date: Mon, 13 Jun 2005 08:49:25 +0100 From: Doug Rabson <dfr@nlsystems.com> To: freebsd-arch@freebsd.org Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no>, Julian Elischer <julian@elischer.org>, arch@freebsd.org Subject: Re: Retiring static libpam support Message-ID: <200506130849.26026.dfr@nlsystems.com> In-Reply-To: <42A75591.7080502@elischer.org> References: <864qc9mgqc.fsf@xps.des.no> <42A75303.2090203@elischer.org> <42A75591.7080502@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 08 June 2005 21:31, Julian Elischer wrote: > adding more to my revious mail.. > > Julian Elischer wrote: > > Dag-Erling Sm=F8rgrav wrote: > >> Julian Elischer <julian@elischer.org> writes: > >>> I gues it would be ok if the basic binary is static and the PAM > >>> modules are loaded using dlopen. > >> > >> You can't load dynamic objects from a static binary. It doesn't > >> have a working dlopen() (since dlopen() is implemented by the > >> run-time loader), and even if it did, there is no relocation table > >> there to resolve dependencies in the dynamic object. > > > > so basically that would screw us. > > Or force us to abandon static linking of apps, > which might be an OK decision, but basically > I think it's kind of the thin edge of the wedge for fully > desupporting all static > binaries. if nothing that does authentication > can be static then there is no such thing any more as a fully static > system and one might as well just not bother. You can link statically to some libraries and dynamically to others -=20 that might work quite well. You would probably end up linking=20 dynamically to libc otherwise you might get two copies of libc when you=20 load a pam module.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506130849.26026.dfr>