And a follow-on
----- Forwarded message from Andrew Haley <aph@redhat.com> -----
From: Andrew Haley <aph@redhat.com>
Date: Wed, 4 Jul 2007 11:21:11 +0100
To: Wookey <wookey@aleph1.co.uk>, Aurelien Jarno <aurel32@debian.org>
Subject: Re: debian java libffi patches
X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO,
RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7-deb, No
Andrew Haley writes:
> Wookey writes:
> > On 2007-07-03 17:02 +0100, Andrew Haley wrote:
> > > aph@hedges:~$ apt-get source libjava
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > E: You must put some 'source' URIs in your sources.list
> > > aph@hedges:~$ apt-get source libgcj
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > E: You must put some 'source' URIs in your sources.list
> >
> > Only the binary repositories were listed (sources not normally needed
> > here, you are expected to be operating in the chroots).
> >
> > I've added source repositories too - should work now.
> >
> > (I fell off the net for a couple of hours after the thunder and
> > lightning)
>
> Ah. :) Remarkably, all the machines here stayed up despite the brownouts.
>
> Anyway, I have a problem. The linker is complaining about overflows
> in relocs, and I can see why:
>
> 2d9c: ebfffffe bl 0 <lt_dlopenext>
> 2d9c: R_ARM_PLT32 lt_dlopenext
>
> This looks to me like offsets from an instruction to the PLT have to
> be contained within 24 bits. Is that correct? The text section of
> libgcj (unoptimized) is 52794995 bytes, which I reckon needs a 26 or
> 27 bit offset field, depending on whether the bl instruction takes a
> signed or an unsigned offset.
>
> size .libs/libgcj.so.9.0.0
> text data bss dec hex filename
> 52794995 4723732 219216 57737943 37102d7 .libs/libgcj.so.9.0.0
>
> Dows the 24-bit limit of the bl instruction impose an absolute limit
> on the size of a shared library?