Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3D2CED4D.5070903@ece.gatech.edu>
Date: Wed, 10 Jul 2002 22:28:29 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3
References: <87fzystrvz DOT fsf AT peder DOT flower> <20020710203841 DOT 2f9c1189 DOT steven DOT obrien2 AT ntlworld DOT com> <3D2C8F96 DOT 2050704 AT ece DOT gatech DOT edu> <20020711015808 DOT GD17469 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/