Policy on static linking ?

Jean-Yves Avenard jyavenard at gmail.com
Sat Jan 15 10:11:51 UTC 2011

On Friday, 14 January 2011, Pete French <petefrench at ticketswitch.com> wrote:
> I build code using static linking for deployment across a set of
> machines. For me this has a lot of advantages - I know that the
> code will run, no matter what the state of the ports is on the
> machine, and if there is a need to upgrade a library then I do it
> once on the build machine, rebuild the executable, and rsync it out
> to the leaf nodes. Only one place to track security updates, only
> one place where I need to have all the porst the code depends on
> installed.

I actually tried to compile a port against another and have it link
statically, but I couldn't find a way to do so without hacking the
configure script. I was wondering if there was another (and easier)
way to do so...

I use ldap for authentication purposes, along with pam_ldap and nss_ldap

If I compile openldap-client against openssl from ports, then it
creates massive problems elsewhere.

For example, base ssh server will now crash due to using different
libcrypto. compiling ports will also become impossible as bsd tar
itself crash (removing ldap call from nsswitch.conf is required to
work again)

I was then advised in the freebsd forums to uninstall openssl port,
compile openldap against openssl base, install it, then re-install
openssl port.
(I have to use openssl from ports with apache/subversion to fix a bug
with TLSv1 making svn commit crash under some circumstances)

I dislike this method, because should openldap gets upgraded again and
be linked against openssl port, I will lock myself out of the machine
again due to sshd crashing. Just like what happened today :(

So how can I configure openldap-client to link against libssl and
libcrypto statically?


More information about the freebsd-stable mailing list