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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
