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
Message-ID: <39B1E8D9.C3379B00@ece.gatech.edu>
Date: Sun, 03 Sep 2000 01:59:53 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sources DOT redhat DOT com
CC: gvv AT techie DOT com
Subject: Re: DLL naming conventions
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



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.

Again, ONLY if ALL cygwin exec's go into /usr/bin, along with ALL cygwin
dlls.  But what of the locally-compiled rxvt, that depends on (say) the
libXpm.dll, where libXpm.dll is part of official package
'libXpm-3.4k-2.tar.gz' in /cygwin/contrib?

Poor little rxvt.exe goes into /usr/local/bin, and will have to rely on
the good offices of Windows to locate libXpm.dll in the search path. 

Or, what of perl.exe, which depends on:
  libdb.dll
  libgdbm.dll
  libz.dll (actually, module Compress:Zlib)
which are all part of the official distro, so they live in /usr/bin. 
But, perl is not official -- it lives in /usr/local/bin.  To insure that
the 'right' libz.dll gets loaded (and I've got two on my machine -- one
cygwin, one native), I have to insure that D:\cygwin\usr\bin precedes
D:\Utils in the global path.   

That's okay, when I run cygwin in a sandbox (Michael's 'User 1') which
is my normal mode of operation.  However, User 2, who only occaisionally
calls cygwin exe's from a normal command prompt (no bash, so can't set
PATH specially for Cygwin in his .bashrc) -- he might have D:\Utils
precede D:\cygwin\usr\bin.

The odds of this occurring are, admittedly, rather low.  If the goal is
to pre-emtively prevent these confusing failures, in the hopes of
lightening the support load on the cygwin mailing list -- we've already
failed! :-) We've already spent far more time discussing this
hypothetical problem that it would take to tell one hundred newbies:
"Put /usr/bin in the front of your path".

> 
> 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.

Two issues have been intermingled -- (1) the 'cyg' prefix/runtime
loading "problem", and (2) the library versioning problem.  Granted, (1)
is very low probability -- see my arguments below.  (2) has not yet bit
us, because most contrib libraries have been dll-ized by me, and each
successive version of the dlls have been interface-compatible, so no
explicit versioning has been necessary. It will become necessary
eventually -- might as well discuss it now.

So, two fairly controversial topics have been co-mingled -- and
sometimes confused with each other -- so we've got 'furor'.

I did observe the dll-runtime loading problem, when I built a native
XEmacs that depended on native libz, libpng, and libtiff dll's.  My path
had /usr/bin first, so I got the cygwin libz.dll etc at runtime, and
XEmacs failed.

There were two possible fixed -- AND NEITHER ONE required cygwin
changes: relink my native XEmacs statically, or copy the native dll's
into D:\Program Files\XEmacs\xemacs-21.2.25\i386-pc-win32\  where the
xemacs.exe was.

> 
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
> 

You are correct, as usual, Chris. This is a low-probability error --
UNLESS one has multiple unix-on-windows emulators installed.  Like Paul
Sokolovsky, who apparently has both cygwin and PW.

I dunno if it's worth this much effort and discussion to fix a problem
that happens so rarely, and is fixable by less intrusive means:  
  when operating in PW mode, set your PATH so that the PW /bin,/usr/bin
is first
  when operating in Cygwin mode, set your PATH so that the cygwin
/bin,/usr/bin is first.

> 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? 

Won't fix the problem for exe's that aren't part of the official
install, but you can work around that by requiring that /bin,/usr/bin be
in the front of the path (prior to 'outside' dirs). Even this, though,
will not fix the problem for 'modeless' users (Michael's 'user 2') --
because modeless users don't want /usr/bin in the front.

However, no modeless users (except for Paul) have complained.  Perhaps
Paul should become modal. :-)

> 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.

Yep -- so libtool and dll versioning issues should be addressed.  But it
appears that the 'modal' PATH requirement is the least intrusive method
of fixing the platform-specific dll confusion (e.g. native vs. cygwin
vs. UWin vs. PW dll's, all with the same name).

--Chuck

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