This is the mail archive of the
mailing list for the Cygwin project.
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
>>> 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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html