Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Date: Fri, 7 Dec 2001 20:02:22 -0500
From: Christopher Faylor <cgf@redhat.com>
To: cygwin@cygwin.com
Subject: Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
Message-ID: <20011208010222.GC27247@redhat.com>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20011206124426.B1448@dothill.com> <3C0FB399.2020300@ece.gatech.edu> <01fc01c17f74$0d774a20$0200a8c0@lifelesswks> <3C1164C8.AF785AAC@ece.gatech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C1164C8.AF785AAC@ece.gatech.edu>
User-Agent: Mutt/1.3.23.1i

On Fri, Dec 07, 2001 at 07:54:32PM -0500, Charles Wilson wrote:
>Anyway, they had a problem after upgrading to a new cygwinish dll
>(cygncurses?? I think) w.r.t. load-on-fork.  There's no way setup/rebase
>can be used to avoid that problem a_priori...is there?  (As I recall,
>the person did a 'hand rebase' on his own system to work around
>it...aware that he would have to repeat the process every time he
>updated that problem DLL from the cygwin dist)

A rebase utility for cygwin would be pretty nice, I think.

We could even include a .bat file which could iterate over all of the
dlls in /bin and make sure there were no conflicts.

cgf

--
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/