On Wed, Jan 09, 2002 at 10:44:29AM -0500, Charles Wilson wrote: > However, I don't think it TRULY matters where dlopen'ed DLLs live -- > except that users should not have to add /usr/libexec (or > /usr/lib/perl5/cygwin-multi/auto/ByteLoader/ and > /usr/lib/perl5/cygwin-multi/auto/Data/Dumper/ and ...) to their path. > Also, I do not think that private, dlopened, > not-in-the-public-bin-directory DLLs should be forced to follow the > cygXXXX.dll nomenclature. XXXX.dll, libXXXX.dll, whatever. They're > *private* -- who cares what they are named (although .dll is kindof a > necessity due to windows runtime loader and dlopen issues)
It actually doesn't matter. But since the default path for libexecdir isn't /usr/libexec but /usr/sbin it should go to /usr/sbin. Or better /usr/lib. Or even better, perhaps, /usr/lib/httpd, /usr/share/httpd, ... > The fact is, many packages put private, non-linkable, > unusable-except-by-themselves shared libs into some private structure. > Like perl does. This is okay, IMO. Sure. > However, packages that do this should not require "external assistance" > to find those dlopen'ed shared libs. Either they should be dlopen'ed > using the full path, or main() should add the requisite directories to > the PATH -- but only for its process space, not globally. Agree. > So, IMO it's fine if apache puts its private, dlopen'ed DLLs into > /usr/libexec/apache/modules or whereever -- but it should not require > that /usr/libexec/apache/modules be added to the global PATH. Except for `libexec', agree. > Now, if apache's httpd.exe is inherently linked to LOTS of mod_*.dll > shared libs -- instead of dlopen'ing them -- then I think that's a poor > design decision and apache needs a bit more work to change that to using > dlopen for the module-related DLL's...otherwise, where's the benefit of > using DLL's? You still need to relink httpd.exe every time you add a > new module...might as well use static libs. Agree. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc.
