Being an old curmudgeon, I have historically preferred static linking
for some of the points raised (no external installation dependencies,
I know the application is complete and will work, use of believed good
library versions, custom library patches are possible, etc).
The other response about needing to be explicit at link time about the
libraries in use is something I like in general. A programmer should
know all the dependencies of his application. I find it really
disgusting when some little application uses a library with a huge
dependency base. This is especially true when the application doesn't
use most of that base.
Some applications pull needed library code into their own source tree
and build their own versions. This can be useful in some cases.
Some of the bloatware application do this to excess.
If it is necessary, I don't know how anyone can make a proper and
usable security declaration about an application which is dynamically
linked against other libraries.
On the other hand, the state of shared libraries is probably much
better than the last time I actually cared. People have learned about
maintaining backward compatibility, API versioning, etc.
If you make good decisions about the libraries you depend upon life
can be much better. Don't just select libraries that are flavor of
the day but instead use libraries with good solid history and apparent
ongoing support.
The other response indicates that even libc with some of the core
functionality doesn't work well with static linking. I'm disappointed
about that state of things, but the reasons seem valid. It is also
interesting about system version compatibility and providing shims for
older ABIs.
Also, in this day of interpreted code (perl, etc) much of that code
base is equivalent to dynamically linked. At $DAYJOB I've seen a few
things with their own versions of certain common libraries included.
I've been curious about the reasons but haven't had time to
investigate.
The use of dlopen() also looks to make "plugins" much easier to do
than with statically linked programs. Plugin equivalents in some of
my earlier applications where much trickier to write since they also
needed to be statically linked with a very reduced set of available
support routines (basically none for the things I was doing at the
time).
Today, I probably wouldn't fight using dynamic linking. I do wish
things would continue to provide static libraries unless there are
specific reasons static libraries won't work. I would like to see
libc remain fully functional when statically linked. I would like
documentation about functionality lost when statically linking with
libc.
Mostly just some ramblings,
Stuart
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone
_______________________________________________
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"
