Re: rebase not compilable

[Reini Urban <rurban at x-ray dot at>]

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.

> > sections.cc: In member function `bool Relocations::relocate(int)':
> > sections.cc:366: 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
http://phpwiki.org/  http://murbreak.at/

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