Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <009e01c0155f$fa5ed810$f7c723cb@lifelesswks> From: "Robert Collins" To: 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> Subject: Re: DLL naming conventions Date: Sun, 3 Sep 2000 15:32:31 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 03 Sep 2000 04:22:48.0906 (UTC) FILETIME=[9E0BDAA0:01C0155E] I have only 1 concern with putting the .dll's in the same directory as an application that needs them... you have to copy n instances of an updated .dll to upgrade a library. i.e. if you have gnome, and gtk+ is updated you have to copy the new .dll to 5-10+locations, depending on the number of applications you have... Does anyone know exactly where the registry DLL location list goes in the dll search order? Or does the application have to use it? That might offer an alternative search mechanism we could place in cygwin(and yes I'd be happy to put some time into writing it - although with no guarantees about time-frame), without writing a brand-new run-time loader... Rob ----- Original Message ----- From: "Chris Faylor" To: Cc: Sent: Sunday, September 03, 2000 1:19 PM Subject: Re: DLL naming conventions > 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. > > cgf > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com > > -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com