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]
