Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3C3C655D.9040708@ece.gatech.edu>
Date: Wed, 09 Jan 2002 10:44:29 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: [ANN] apache_1.3.22 package available for setup inclusion
References: <3C3BFC4C DOT 15C3C81A AT wapme-systems DOT de> <885801411 DOT 20020109124743 AT familiehaase DOT de> <3C3C5978 DOT 20076688 AT wapme-systems DOT de> <20020109160306 DOT C21035 AT cygbert DOT vinschen DOT de> <3C3C5F22 DOT 6E3D8286 AT wapme-systems DOT de> <20020109162447 DOT E21035 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On the location of DLLs:
   I agree with Corinna that "inherently linked" DLL's should be in 
/usr/bin, and should be named "cygXXXXX.dll" not "libXXXXX.dll". 
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)

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.

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.

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.

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.

--Chuck

Corinna Vinschen wrote:

> On Wed, Jan 09, 2002 at 04:17:54PM +0100, Stipe Tolj wrote:
> 
>>>  --prefix=/usr
>>>  --sysconfdir=/etc
>>>  --libexecdir='$(sbindir)'
>>>  --localstatedir=/var
>>>  --datadir='$(prefix)/share'
>>>
>>>I'd agree to change the sysconfdir to sth. below /etc as /etc/httpd
>>>but I don't see a reason to change libexecdir.
>>>
>>So you want to keep the *.dlls in /usr/libexec?
>>
> 
> No.  See my other mail.  What I meant was, $libexecdir should be
> == $sbindir == $(prefix)/sbin == /usr/sbin.
> 
> DLLs to
> 
> /usr/lib	if run time loaded with e.g. dlopen()
> /usr/bin	if inherently linked in.
> 
> Basically I don't want /usr/libexec in the users path.
> 
> Corinna
> 
>