binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3]

[Charles Wilson]

Also, while you're at it, how about this patch from Ralf:
   RE: cygwin ld import library issue fix (removing unused "_nm_" symbols)
   http://sources.redhat.com/ml/binutils/2002-04/msg00416.html

After re-reading the whole thread, it seems that everybody (eventually) 
thought it'd be a good idea, but a check of CVSweb shows that it never 
actually got applied.

--Chuck

Charles Wilson wrote:

> Christopher Faylor wrote:
> 
>> On Wed, Jul 10, 2002 at 03:48:38PM -0400, Charles Wilson wrote:
>>
>>> There is a patch pending to binutils that would allow this to work 
>>> as-is.  It seems to work okay, however, we're still waiting on Egor's 
>>> legal paperwork -- an unfortunately, the only discussion has been 
>>> between Egor and I; no other binutils-list readers have commented.
>>>
>>
>> Should I make a "test" version of binutils available with Egor's patch?
>>
>> Oh wait.  It needs a new version of cygwin1.dll first.  I guess we have
>> to release it as 1) cygwin and 2) binutils.
> 
> 
> 
> Err, not really.
> 
> I can test his patched binutils under stock 1.3.12-2. That is, I can 
> build a library with struct FOO_struct my_array[].  I can successfully 
> build a client that accesses my_array[3].bob, and the runtime 
> pseudo-relocation works just fine.
> 
> As long as my client doesn't fork().
> 
> The reason for the cygwin patches, is so that the above works after a 
> fork(), because the runtime pseudo-relocs have to be redone in the 
> child.  I think.
> 
> So, the worst that could happen if you release a patched binutils but 
> not cygwin, is that
>   1) IF some one exercised this feature
>   2) and they fork()
>   3) then it will break.
> But all existing working code will continue to work -- since with 
> existing binutils we can't even LINK code that might exercise the feature.
> 
> So, worst case: some new code (that currently doesn't work) might 
> continue to not work -- except right now it's a build error; it'll 
> become a runtime error (but only in fork()ed children).
> 
> Right, Egor?
> 
> Anyway, I think you should go ahead with a test release of binutils 
> *before* a new cygwin release.
> 
> --Chuck
> 
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/