Date: Mon, 13 Jun 2005 10:34:11 -0700 From: Julian Elischer <julian@elischer.org> To: Doug Rabson <dfr@nlsystems.com> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-arch@freebsd.org, arch@freebsd.org Subject: Re: Retiring static libpam support Message-ID: <42ADC393.5080706@elischer.org> In-Reply-To: <8510490ff3a56e4ffcc127064b260caf@nlsystems.com> References: <864qc9mgqc.fsf@xps.des.no> <42A75303.2090203@elischer.org> <42A75591.7080502@elischer.org> <200506130849.26026.dfr@nlsystems.com> <86ll5eyzg0.fsf@xps.des.no> <8510490ff3a56e4ffcc127064b260caf@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > > On 13 Jun 2005, at 17:49, Dag-Erling Smørgrav wrote: > >> Doug Rabson <dfr@nlsystems.com> writes: >> >>> You can link statically to some libraries and dynamically to others >>> - that might work quite well. You would probably end up linking >>> dynamically to libc otherwise you might get two copies of libc when >>> you load a pam module. >> >> >> That won't help. You'll still end up with two copies of *libpam*. > > > It depends exactly what Julian needs to link with statically - it > wasn't clear. When I build my own software 'statically' I tend to > still link to the system libraries dynamically. We tend to try build fully static binaries as that reduces the number of support calls we get due to mismatched libraries. the answer may be to staticaly link 90%.. i.e everything except libc or something similar.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42ADC393.5080706>