Policy on static linking ?

Pete French petefrench at ticketswitch.com
Fri Jan 14 14:07:39 UTC 2011


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 recently wanted to use libdespatch, but I found that the port
didn't install the static libraries. I filed a PR, and found out
from the reponse that this was deliberate, and that a number of
other ports were deliberately excluding static libraries too. Some
good reasons where given, which I wont reporduce here,
as you can read them at: http://www.freebsd.org/cgi/query-pr.cgi?pr=151306

Today I finally hit the problem where a critical library I am using
has stopped working with static libraries (or so it appears at first glance).
I was wondering what the general policy here was - should I just bite the
bullet and go dynamic, and accept the maintannance headache that cases, or
could we define something like 'WITH_STATIC_LIBRARIES' that could be set
which would make ports install a set of static libraries (maybe into
a separate /usr/local/lib/static?) so that the likes of me could
continue to build static code ? I'd very much like to be able to continue
to ship single executables that "just run", but if theres some policy
to only have dynamic libraries in ports going forward then fair enough...

-pete.


More information about the freebsd-stable mailing list