Re: ld --auto-import for cygwin and libtool

[Christopher Faylor <cgf at redhat dot com>]

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