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
Date: Mon, 23 Jul 2001 01:15:46 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: ld --auto-import for cygwin and libtool
Message-ID: <20010723011546.A3274@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <020601c0f27b$d579ea90$0200a8c0 AT lifelesswks> <02a701c11289$bc8b9b90$562fa4cb AT co3007967a> <007e01c112b0$a6de11c0$806410ac AT local> <033a01c112b2$306e53e0$562fa4cb AT co3007967a> <3B5B0686 DOT 5050500 AT ece DOT gatech DOT edu> <009d01c11315$90a94d60$562fa4cb AT co3007967a> <20010722224246 DOT D9168 AT redhat DOT com> <010501c11321$d1b7d9a0$562fa4cb AT co3007967a> <20010722230939 DOT F9168 AT redhat DOT com> <3B5BAA35 DOT 1030306 AT ece DOT gatech DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <3B5BAA35.1030306@ece.gatech.edu>; from cwilson@ece.gatech.edu on Mon, Jul 23, 2001 at 12:38:13AM -0400

On Mon, Jul 23, 2001 at 12:38:13AM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>
>
>> It's possible that I might be convinced to include Paul's patches in the
>> next binutils release if they are not incorporated into the official
>> release.  However, I would rather use the official CVS release, if
>> possible.
>> 
>
>
>Yes.  And to that end, I'm building and testing stuff.  Specifically, 
>binutils with Paul's patch.  autoconf(latest).  automake(latest). 
>Robert Collin's libtool(which relies on ld-with-Paul's patch).  etc. 
>Rebuild one of "my" packaged dll's using Paul's ld (readline or 
>something) and make sure old exe's that depend on it still work when I 
>drop in the new dll.  And vice versa: check that exe's compiled with 
>Paul's ld, against the new dll, still work if I revert to the old dll. 
>etc. etc.
>
>In other words, in addition to the major testing that Robert gave this, 
>I'm also now looking at it.  However, I understand that one of the 
>sticking points has been the relocation of cygwin1.dll from parent to 
>child across fork().  See thread "dll base address" in the 
>cygwin-developers archive:
>   http://www.cygwin.com/ml/cygwin-developers/2001-06/msg00037.html

I think that was eventually discovered to be a non-issue.  I believe
that someone was building the "helper DLL" so that it occupied the same
space as cygwin1.dll normally does.

I eventually reluctantly admitted that maybe the cygwin DLL should be
considered non-relocatable so that we could use a sledge-hammer approach
to fixing the "problem" of ensuring that the cygwin DLL always occupy
the same location in the parent and the child.  IMO, this is not a
high priority issue but if you can get a working unrelocatable DLL then
I guess that would be great.  I wonder if it even loads faster.

cgf