X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_22,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49C27968.90500@users.sourceforge.net>
Date: Thu, 19 Mar 2009 11:57:12 -0500
From: "Yaakov (Cygwin/X)" <yselkowitz AT users DOT sourceforge DOT net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] /usr/bin no longer in default LD_LIBRARY_PATH
References: <49C210EA DOT 8080204 AT users DOT sourceforge DOT net> <20090319102741 DOT GA26397 AT calimero DOT vinschen DOT de>
In-Reply-To: <20090319102741.GA26397@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Corinna Vinschen wrote:
> If a DLL can't be found in a given PATH, Cygwin 1.5.25's function
> searching for the DLL (get_full_path_of_dll) just left the filename
> alone.  The following LoadLibrary call then used the default DLL search
> order, which includes the $PATH variable, thus a DLL in /usr/bin is
> found.
> 
> Since July last year, Cygwin 1.7's get_full_path_of_dll function always
> converts a filename to a full pathname, even if the file isn't found.
> The resulting full pathname is $cwd/filename.  This effectlvely
> suppresses the Win32 default DLL search path in LoadLibrary, thus using
> either LD_LIBRARY_PATH, or /usr/lib.  From a POSIX perspective it's
> wrong to rely on the default Win32 DLL load order in dlopen() and the
> behaviour of dlopen() in 1.5.25 was a bug rather than a feature.
> 
> Bottom line is, I'm sure the new behaviour is more correct, but if
> you have a convincing argument to revert to the old behaviour, I'm
> certainly open for discussion.

First, it's a huge regression.  This breaks *lots* of existing code.

Now, at risk of stating that which you already know quite well:

Using /usr/lib as the default LD_LIBRARY_PATH makes sense on *NIX
platforms where the shared libraries are themselves in PREFIX/lib, and
LD_LIBRARY_PATH is used not only by dlopen() but by ld.so for runtime
linking as well.

It goes without saying that this is not the case on Cygwin.  We rely on
Windows' runtime linker, which resolves using PATH.  Therefore we put
all our shared libraries in PREFIX/bin, which anyways need to be in PATH
to run commands from there.

Being so, WRT dlopen(), it doesn't make much sense to look in /usr/lib
for libraries which aren't there!  In fact, among the many packages in
Ports, only four packages install their DLL modules directly into
/usr/lib, and three of those use libltdl anyway (which, BTW, uses PATH
on Cygwin instead of LD_LIBRARY_PATH for resolving DLLs!).

So as it stands now, dlopen() finds, well, just about nothing.

How could we proceed?

We could keep the code as is, but since we install DLLs to /usr/bin and
add it to PATH, we need to add it to LD_LIBRARY_PATH as well.  Those who
add /usr/local/bin (or ~/bin) to their PATH will need to add it to their
LD_LIBRARY_PATH also, so you end up with nearly identical PATH and
LD_LIBRARY_PATH values.

OR we could revert the code to allow searching in PATH as before, since
that's where the DLLs actually reside.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAknCeWgACgkQpiWmPGlmQSMtSQCfX5mpfQRKkenAVwamJF2qff9V
7j4An1xko0qFH0u7OeeiHTE37Pk2njGa
=cwJB
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/