Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Sun, 3 Sep 2000 12:30:18 -0400
To: cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
Message-ID: <20000903123018.A22158@cygnus.com>
Reply-To: cygwin AT sources DOT redhat DOT com
Mail-Followup-To: cygwin AT sources DOT redhat DOT com
References: <200009011148 DOT OAA23769 AT urkki DOT tellabs DOT fi> <39AFB333 DOT 69CE5F95 AT ece DOT gatech DOT edu> <20000902140958 DOT F7695 AT demon DOT co DOT uk> <39B14893 DOT A86AF3F9 AT ece DOT gatech DOT edu> <20000902231925 DOT Q7695 AT demon DOT co DOT uk> <20000902221915 DOT B13854 AT cygnus DOT com> <20000903132712 DOT B7695 AT demon DOT co DOT uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <20000903132712.B7695@demon.co.uk>; from gvv@techie.com on Sun, Sep 03, 2000 at 01:27:12PM +0100

On Sun, Sep 03, 2000 at 01:27:12PM +0100, Gary V. Vaughan wrote:
>On Sat, Sep 02, 2000 at 10:19:15PM -0400, Chris Faylor wrote:
>> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> >> Since windows-dll
>> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> >> similar, you've got a problem.
>> >
>> >Most definitely.
>> 
>> It is *not* strictly based on the executable path.  It first searches
>> the current directory, then searches the directory containing the executable.
>> Most Windows packages rely on this and place the DLL with the executable.
>> That should solve the problem of finding the "wrong" dll.
>> 
>> I'm still kind of amazed by all of the furor this discussion is generating,
>> given that I don't think we have yet seen a single problem reported.
>> 
>> If this was a big deal I would have thought that there would be many many
>> plaintive wails in this mailing list.
>> 
>> If the solution to the problem is as simple as placing the DLL with the
>> executable then why the heck don't we just do that?  I love being as
>> close to UNIX as possible but if it is going to cause problems then
>> it makes sense not to do things that way.
>
><rant>
>Why not just statically link all of our applications?  Then we
>wouldn't have any problems with wrong dlls being loaded at all!
>
>Everyone agrees that shared libraries on Unix are a good idea, right?
>How come so many of us think that the best way to use shared libraries
>on Windows is to make them as much like static libraries as we can?
>The closest thing to a static library *is* a static library.  Lets get
>off the fence here.  If we want static libraries then fine, I'll shut
>up and go away.  If we want shared libraries, wouldn't it be cool to
>hammer out the easiest (from a man-hours effort point of view) way to
>take advantage of the benefits they can offer?
>
>The whole point of a shared library, is that it is shared by the
>applications that use it.  You can upgrade all of the applications
>that use it by updating the shared library.  You only need to have one
>copy in memory.
>
>Putting a copy of all the dll's used by each application into the
>directory the application loads from defeats the purpose.  I know dll's
>are sucky compared to ELF shared libraries, and that the windows
>runtime loader is sucky compared to ld.so.  But wouldn't it be nice to
>have some of the advantages shared libraries bring to Unix when we use
>cygwin?  I'm even offering to do most of the work by making all the
>libtool using packages (i.e. just about everything from gnu.org and a
>whole buch of other stuff too) conform to whatever scheme we agree
>will work the best.  I'll bet that if we converted the non-libtool
>packages that we port to an autoconf/automake/libtool build system,
>the upstream maintainers would incorporate the patch into the real
>version, and the next release would work on cygwin out of the box.
>Assuming we choose a good scheme for libtool built dlls on cygwin.
></rant>

Are you ranting at me?  Don't bother.

Chuck Wilson has adequately explained why "just put the DLL in
the same directory" isn't a perfect plan.

Regardless, I wasn't advocating putting each executable in its own
directory with a DLL.

My major concern was naming every cygwin DLL "cygsomething.dll".  I
really don't like that idea, especially since it will mean work for
people at Red Hat to accomodate.

If you have a plan that doesn't require changing the name of libz.dll to
something like cyglibz.dll then I have no objections.

I did see the AppPath registry key being mentioned.  I'm not sure how
libtool could make use of that since that is something that is set on
installation of a package.  libtool may be out of the picture at that
point unless you're doing 'make install'.

I think it may be possible to have a dll that is loaded before most
other dlls change the PATH so that something like /usr/lib is first in
the path, removing the /usr/lib prior to execution of 'main()'.  We
could, in fact, even add a front end to kernel32.dll which did this.

This could be a solution for cygwin but I don't know if it addresses the
problem of other packages or not.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com