Mail Archives: cygwin-apps/2001/07/23/01:41:05
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
- Raw text -