This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rebase not compilable

On Mon, Jun 02, 2008 at 07:03:18PM +0200, Reini Urban wrote:
> Brian Dessent schrieb:
>> Reini Urban wrote:
>>> I thought I'll improve the rebase logic by adding some fixed base
>>> addresses and space to certain apps
>>> (bash, perl, python, rest) to be able to properly rebase the culprit
>>> packages in advance.
>>> I wanted to start with
>>>   /usr/bin/bash.exe
>>>   /usr/bin/cygintl-8.dll
>>>   /usr/bin/cygiconv-2.dll
>>>   /usr/bin/cygreadline6.dll
>>>   /usr/bin/cygncurses-8.dll
>>> starting at -b 0x70000000 -o 0x10000 downwards,
>>> then perl downwards with some reserve,
>>> then python downwards with some reserve,
>>> then fix rebaseall to work with bash and use the new base belowe python,
>>> so that for a rebaseall only the cygwin services have to be stopped.
>> Is this really a good direction to move in?  The long term plan, as I
>> understood it, was to simply build everything with
>> --enable-auto-image-base and avoid forever the problem of having to
>> manually rebase ever.  Rebaseall is just a crutch to get us there while
>> we still have legacy packages built without having image bases assigned
>> by the hash; it should not be considered a permanent solution.
> I use --enable-auto-image-base for all standard dll's within perl, but 
> nevertheless I got base conflicts.
> auto-image-base just uses a quasi-random hash based on the file contents 
> (or header), which is obviously too fragile for my sum of dll's.
> For the few packages like bash, perl and python which fail into this trap, 
> I would rather suggest using some reserved base address space.
> I started for perl with 0x52000000 upwards but this was also not enough.
> So I tried it with a custom rebase and rebaseall first.
> rebaseall being bash enabled again, which would be a big winner.

Maybe we should start a dll registration program for the release?  I doubt
that there are enough addresses available to accommodate every dll but maybe
we could at least minimize the damage by assigning base addresses to known


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]