X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Ross Patterson <me AT rpatterson DOT net>
Subject:  Re: Cygwin Python/PIL TCL/TK fork rebase solution
Date:  Tue, 16 Jan 2007 18:56:38 -0800
Lines: 36
Message-ID:  <874pqqfjix.fsf@superfluity.lefae.org>
References:  <87ejpvluvj DOT fsf AT superfluity DOT lefae DOT org> 	<3D1F5241A4BA56B7EBA1D30B AT qjunbur DOT quns DOT cam DOT ac DOT uk> 	<45ACC59F DOT 397A6589 AT dessent DOT net> <45ACCBEF DOT 49170261 AT dessent DOT net> 	<C997D9C1A0EA00B6C5A47F1F AT qjunbur DOT quns DOT cam DOT ac DOT uk> 	<20070116175838 DOT GB14405 AT trixie DOT casa DOT cgf DOT cx> 	<87zm8ihmhd DOT fsf AT superfluity DOT lefae DOT org> <45AD1E15 DOT 31F06B43 AT dessent DOT net>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.92 (gnu/linux)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

Brian Dessent <brian AT dessent DOT net> writes:

> Ross Patterson wrote:
>
>> I'd still like to understand how one chooses base address and offset
>> values for rebase, seeing as I was just shooting in the dark until
>> something said "OWW!"  :)
>
> Well normally you don't really choose anything.  There are two ways to
> assign the base address.  And again keep in mind that for a lot of
> users, this won't matter; it tends to only comes into play in the
> presence of dynamically loaded modules.
>
> If you run rebaseall, it just takes a list of all known Cygwin DLLs on
> the system (based on the /etc/setup/*.lst.gz files created by setup) and
> starting at some address near the top of memory (currently 0x70000000
> but this might have been 0x68000000 in the recent past) it assigns them
> in back to back slots, in descending order.  This should fix most
> problems as it ensures that every known DLL loads to a unique spot in
> virtual memory.

Interesting, in my case, rebaseall wasn't working.  I just verified
that tk84.dll was in the /etc/setup/*.gz files and it was.  I'm
assuming that /usr/bin/tk84.dll is the same file as /bin/tk84.dll,
because /usr/bin/tk84.dll is what was in the /etc/setup/*.gz file but
/bin/tk84.dll is what I had to rebase to fix my problem.

> But it requires the user to run rebaseall, which in turn requires that
> all DLLs be not in use so they can be modified, and it requires that
> once this has been done the first that it be repeated any time a new
> DLL-containing package is installed. 

Yup, I did my rebaseall calls after a reboot and before I did anything
else every time.

Ross


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/