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

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. In member function `bool Relocations::relocate(int)': error: ISO C++ forbids cast to non-reference type
used as lvalue
make: *** [sections.o] Error 1

The cast-as-lvalue was a nonstandard gcc extension that was disabled in C++ mode (and deprecated for C mode) starting with gcc 3.4.x. Likely this package is so old that it was last built with gcc 3.3.x which still allowed the construct. So, one workaround is to temporarily install the [prev] version of gcc-g++ and gcc-core which are the 3.3 versions.

I know.
I wanted to hear some magic g++ --allow-non-ansi switch (-std=c89 or such for C++) or some INT2PTR macro.

$ g++ --help|grep ISO
is empty
Reini Urban

Unsubscribe info:
Problem reports:

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