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: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B24EB50.94F666B3@ece.gatech.edu>
Date: Mon, 11 Jun 2001 12:01:20 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
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>
Subject: Re: ld --auto-import for cygwin and libtool
References: <020601c0f27b$d579ea90$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Collins wrote:
> Paul a while back made a rather neat hack to pe to allow automatic
> importing of symbols without needing decoration. 

Note that this involves a very minor violation of the PE spec, but so
far no MS runtime linker (Win9x, ME, NT, 2K, XP-beta?) has had a problem
with dll's produced this way. 

> This allows libraries
> to be built with out any decoration in the headers - ie in standard UNIX
> format. AFAIK the patch has languished due to no one reviewing it.
> 
> So... I've spent some time putting it through it's paces, and it seems
> to work without any issues at all. There were some teething issue, due
> to the patch not being developed for Cygwin, but for pw32. Thats been
> resolved (see below).

Thank you, Robert!

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

> 2) quote.test - which I have discussed in the copied email below.

> I've also uploaded a binutils src tarball with the modified ld. I've
> modified it a little further to avoid some cygwin dll symbols it was
> picking up by mistake. A patch for that against a recent binutils is
> there as well. My patch also differs from Paul's original in that I've
> left disabled the auto-image-base option, which can cause issues with
> cygwin, due to a issue previously discussed. That option isn't part of
> the auto-import logic and thus shouldn't be part of this discussion IMO.
> (And should not be enabled by default!).

Just to make sure:
  current cygwin ld, --disable-auto-image-base is the default
  Paul's modified ld, --ENABLE-auto-image-base is the default
  Your modified ld, --disable-auto-image-base is the default
Right?  If so, then I agree with your decision to keep that out of the
current discussion.  That change is orthogonal to the auto-imports
stuff.
 
> ----- Original Message -----
> From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> To: "Gary V.Vaughan" <gary AT oranda DOT demon DOT co DOT uk>
>
> > (the failures are: quote.test is failing, "error on mkdir .libs" but I
> > think thats because cygwin returns an error when you mkdir an existing
> > directory - does unix return an error for that? 

Yes.  (at least, bash somehow realizes that an error occurs, and prints
the error message.  I assume that is because the mkdir() kernel call
*itself* reports ESOMETHING.)  On Linux-2.4:

[cwilson AT polgara cwilson]$ mkdir evolution
mkdir: cannot create directory `evolution': File exists

> > I have one change that definately isn't a proper solution - and thats
> > the extra_LIBS thing I asked about on the list a few days ago. The
> .dll
> > needs to go in the search path, or the test script needs to add the
> > libs/extra dir to the normal path when the test is run on  cygwin, for
> a
> > proper solution.

Hmm...is this for the "link directly to the dll without using an import
lib; instead generate a virtual implib on-the-fly" behavior?  Why is
this necessary?  Can't you just use an implib? I'm not sure of the
context, here; please elaborate...

--Chuck