This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: HEADSUP: Python 2.7 upgrade
On Jan 24 06:49, marco atzeri wrote:
> On 1/24/2013 1:56 AM, Yaakov (Cygwin/X) wrote:
> >Jason Tishler announced last month[1] that he intends to upgrade Python
> >to 2.7 on 01 February, which is quickly approaching.
> >
> >If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
> >
> >ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
> >
> >In order to assure a prompt and smooth transition to Python 2.7, the
> >following packages will need a rebuild/update:
> >
>
> >Marco Atzeri: postgresql
>
> postgresql upgrade is blocked by a rebase/objcopy issue
>
> http://cygwin.com/ml/cygwin/2013-01/msg00199.html
>
> also patching cygport to use
> "--long-section-names enable" together with "--add-gnu-debuglink"
>
> one of the dll "dict_snowball-dll" causes rebase to segfault
>
> I am not sure if it is objcopy creating a bugged debuglink dll,
> or it is rebase incorrectly choking on it.
I debugged this last week, and I don't see how this could be a rebase
bug. The layout of the relocation information is basically an array
of relocation blocks, like this:
.reloc section
block1
header
base offset
sizeof following array
array of 2 byte values with:
4 bit relocation type
12 bit offset from base offset
block2
[...]
The size of the .reloc section in the file header does not indicate how
long the relocation information in the section actually is. Usually the
section is larger than the actual relocation info. The end of the
relocation info is indicated by a block header with a base offset of 0
and a sizeof of 0, let's call it the NULL block.
What I could reproduce using Marco's ltree.dll example was this:
After adding the .gnu_debuglink section, the former NULL block suddenly
contained some seemingly random values. So rebase rightfully assumed
that another relocation block is following. So it happily tried further
to relocate the file, until the address falls outside of the allocated
memory block, which resulted in the SEGV.
To me this indicates a bug in objcopy.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat