Mail Archives: cygwin-apps/2002/01/09/15:26:04
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:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -