Joshua, 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.
-Len 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 does now. 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 code changes... Josh Joshua Megerman 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 [EMAIL PROTECTED]
-- "Do not go where the path may lead, go instead where there is no path and leave a trail." ~ Ralph Waldo Emerson ~
