Mail Archives: cygwin-apps/2001/06/11/19:13:45

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
From: "Gary V. Vaughan" <gary AT oranda DOT demon DOT co DOT uk>
Organization: GNU
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
Date: Mon, 11 Jun 2001 23:46:07 +0100
X-Mailer: KMail [version 1.2]
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>
References: <020601c0f27b$d579ea90$0200a8c0 AT lifelesswks> <3B24EB50 DOT 94F666B3 AT ece DOT gatech DOT edu>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <0106112346071M.15044@cain>

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 

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

  ())_.  Gary V. Vaughan     gary@(|
  ( '/   Research Scientist        ,_())____
  / )=   GNU Hacker   \'      `&
`(_~)_   Tech' Author    =`---d__/

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019