I think this is a worthwhile endeavour for many of the reasons you
discuss below, as well as one more. It makes linking applications
such as courier-authlib much easier. I recently ran into trouble with
this under NetBSD-i386. I did not know of a historical patch, I have
not been with vpopmail for long. I ended up tweaking the build of
vpopmail-5.4.20 to create the shared library. I also notice on this
OS that separate from this, the binaries are building as dynamically
linked. I would definitely provide the option to build static; I
don't see a real need to do so selectively for different binaries. As
regards performance, I am not qualified to speak but I doubt we would
see much difference. Most modern operating systems are built on
shared libs. Thanks to all for the hard work you do on vpopmail, it
is an impressive package.
On Mon, 24 Sep 2007, Joshua Megerman wrote:
Following up on my recent post to [vchkpw], I did some digging back into
the history of the shared libvpopmail patch and the discussions
surrounding it, and have the following thoughts.
First off, let me prefice this by saying that while I understand the
concept of shared libraries, I don't understand the underlying mechanics
of how the OS handles them, and thus am not sure exactly how can be
affected performance-wise. That being said, here's my thoughts:
1) A shared library with a stable API would make recompiling outside
programs (e.g., QmailAdmin) unnecessary, which would be a Good Thing(tm).
2) There has been some question regarding performance of the vpopmail
programs when compiled against shared vs. static libraries. I suggest the
following options be added for shared libraries at compile-time:
a) --disable-shared - don't build libvpopmail.so, which is what vpopmail
b) --enable-shared - build libvpopmail.so, but don't link the vpopmail
binaries against it - this gives other programs the ability to use the
shared library, but keeps the vpopmail binaries statically linked.
c) --enable-shared-binaries - build libvpopmail.so and link the vpopmail
binaries against it. Implies --enable-shared.
d) possibly, if it's not to difficult, have a --enable-shared-binaries=
and/or --enable-static-binaries= option, which takes a list of binaries
to link against the stated library, and links the rest against the
other. So you could have static vdelivermail and vchkpw, but not
vadduser, for example. Not sure if that really is necessary, but static
linking does save space...
3) In all cases, even if the vpopmail binaries are linked against the
shared library, the static library libvpopmail.a should be built since
some programs expect it.
Also, just a supposition on my part, but if you're running (e.g.)
courier-authdaemon linked against libvpopmail.so all the time, wouldn't
that (theoretically) mean that other dynamically linked vpopmail programs
would run faster than the static version since the library would already
be loaded in memory? If so, perhaps the speed solution for a dynamic
(e.g.) vdelivermail would be to run something that was dynamically linked
all the time, so libvpopmail stayed in memory...
Anyway, that's it for now - I haven't even tried the patch against the
latest vpopmail, though I'm guessing it should be fairly easy (albeing
possibly tedious) to integrate since it's not much in the way of actual
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
"Do not go where the path may lead, go instead where there is no path
and leave a trail."
~ Ralph Waldo Emerson ~