This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld --auto-import for cygwin and libtool
- To: "Charles S. Wilson" <cwilson at ece dot gatech dot edu>,Robert Collins <robert dot collins at itdomain dot com dot au>
- Subject: Re: ld --auto-import for cygwin and libtool
- From: Gary V. Vaughan <gary at oranda dot demon dot co dot uk>
- Date: Mon, 11 Jun 2001 23:46:07 +0100
- Cc: libtool at gnu dot org,cygwin-apps at cygwin dot com,binutils at sources dot redhat dot com,Paul Sokolovsky <Paul dot Sokolovsky at technologist dot com>
- Organization: GNU
- References: <020601c0f27b$d579ea90$0200a8c0@lifelesswks> <3B24EB50.94F666B3@ece.gatech.edu>
On Monday 11 June 2001 5:01 pm, Charles S. Wilson wrote:
> Robert Collins wrote:
> > 1) build-relink.test spits out
> > "shlibpath_overrides_runpath should be set to yes."
> > I'm not sure what that should be for cygwin, so I'm referring the
> > question to the libtool list :]. I'm happy to dig further if the issue
> > is a bug, but if setting this to yes is the correct action there's
> > little to do :].
>
> This isn't an error message, is it? In any case, I don't think the MS
> runtime linker allows the dll itself or an executable to specify a shlib
> search path. The runtime linker always follows this search order:
> (a) look in the same directory as the executable which needs the
> shlib.
> (b) search the system $PATH
> Win2K added a new twist, but I forget the details. Something about
> adding a second file in the same directory as the exe (say, foo.exe),
> called 'foo.path' or somesuch. That second file can then specify where
> the needed dlls should be searched for first. Or something. This was
> discussed on the cygwin-apps mailing list...go check that for the real
> details. In any case, this second file is a *second* file == the exe
> *itself* can't override the default shlib search path.
>
> So, I think this should be "no" on cygwin (and mingw, and pw32...)
Currently, on the various windows platforms, shlibpath_var is set to PATH,
so setting shlibpath_var does indeed override the runpath (in a manner of
speaking).
There are two ways to fix this:
i) deem that $PATH is _not_ the shlibpath_var and leave it unset.
ii) set shlibpath_overrides_runpath=yes to indicate that this works:
$ PATH=/where/all/my/dlls/live:$PATH foo.exe
The second looks correct to me... and libtool seems to agree with me ;-b
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())____
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/