Re: Building Question

Re: Building Question

[Geoff Hutchison]

I don't know if this is the right place for this, so if it isn't 
please just point me in the right direction.

I'm the head maintainer for the ht://Dig project and I do all of my 
development and compilation on my LinuxPPC R5 partition. We recently 
switched to using libtool, allowing shared and static libraries.

Increasingly, I get compilation failures like this:

../htlib/.libs/libht.a(conf.l.o): In function `yyinput(void)':
/home/ghutchis/htdig-cvs/build/htlib/conf.l.cc:1312: undefined 
reference to `yywrap'
/home/ghutchis/htdig-cvs/build/htlib/conf.l.cc:1312: relocation 
truncated to fit: R_PPC_REL24 yywrap
collect2: ld returned 1 exit status

I've seen the "R_PPC_REL24" failure before and it seems to happen 
frequently. I can't seem to find any reference on what the code means 
or how I can fix it. Generally, these failures don't happen for 
people running Linux/x86.

Thanks in advance,
-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Building Question

[Martin Costabel]

Geoff Hutchison wrote:

> Increasingly, I get compilation failures like this:
> 
> ../htlib/.libs/libht.a(conf.l.o): In function `yyinput(void)':
> /home/ghutchis/htdig-cvs/build/htlib/conf.l.cc:1312: undefined
> reference to `yywrap'
> /home/ghutchis/htdig-cvs/build/htlib/conf.l.cc:1312: relocation
> truncated to fit: R_PPC_REL24 yywrap
> collect2: ld returned 1 exit status
> 
> I've seen the "R_PPC_REL24" failure before and it seems to happen
> frequently. 

It happens after "undefined reference" errors.
 
>            I can't seem to find any reference on what the code means
> or how I can fix it. 

Fix the "undefined reference" error.

>                      Generally, these failures don't happen for
> people running Linux/x86.

You mean "undefined reference" isn't an error on x86? 

--:)
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Building Question

[Geoff Hutchison]

At 11:23 AM +0100 11/16/99, Martin Costabel wrote:
>Fix the "undefined reference" error.
>You mean "undefined reference" isn't an error on x86?

That's my point--people compiling the *same* code don't get that error.

At 9:27 AM +0100 11/16/99, Wolfgang Denk wrote:
>I'm not really sure, but can you please check how  big  your  code  /
>data  segments  are? The PPC addressing model is limited in range for
>relative addressing - "REL24" indicates that you are overrunning  the
>relacatable range using 24 bit offsets...

I was afraid of that. Thanks. I'll see if I can tweak the linking 
order and see if that helps a bit. I'll also try gcc -Os and see if 
that helps.

-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Building Question

[Gabriel Paubert]

On Tue, 16 Nov 1999, Geoff Hutchison wrote:

> 
> At 11:23 AM +0100 11/16/99, Martin Costabel wrote:
> >Fix the "undefined reference" error.
> >You mean "undefined reference" isn't an error on x86?
> 
> That's my point--people compiling the *same* code don't get that error.
> 
> At 9:27 AM +0100 11/16/99, Wolfgang Denk wrote:
> >I'm not really sure, but can you please check how  big  your  code  /
> >data  segments  are? The PPC addressing model is limited in range for
> >relative addressing - "REL24" indicates that you are overrunning  the
> >relacatable range using 24 bit offsets...
> 
> I was afraid of that. Thanks. I'll see if I can tweak the linking 
> order and see if that helps a bit. I'll also try gcc -Os and see if 
> that helps.

Note that actually the so called 24 bit is a signed 26 bit value branch
relative offset. This means that you try to jump more than +/-32 Mb away
from the code which is quite strange, unless you are generating megatons
of template based code... (You truly need several millions line of code
or your code is spread across a lot of sections which happen
not to be located together). Check also the linker script if there is
one just in case...

You might also want to use the longcall attribute (I never tested it),
from info gcc: 

`longcall'
     On the RS/6000 and PowerPC, the `longcall' attribute causes the
     compiler to always call the function via a pointer, so that
     functions which reside further than 64 megabytes (67,108,864
     bytes) from the current location can be called.

for portability I would it use it in the following way: 
#ifdef __powerpc__
#define __faraway __attribute__((__longcall__))
#else
#define __faraway
#endif
and then declare the offending functions __faraway...

Note: It might also be used for the linux kernel in modules, declaring a
function longcall would avoid the jump through linker generated (actually
module loader generated) code if I understand correctly what it does.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Building Question

[Geoff Hutchison]

At 5:15 PM +0100 11/16/99, Gabriel Paubert wrote:
>Note that actually the so called 24 bit is a signed 26 bit value branch
>relative offset. This means that you try to jump more than +/-32 Mb away
>from the code which is quite strange, unless you are generating megatons
>of template based code... (You truly need several millions line of code
>or your code is spread across a lot of sections which happen
>not to be located together). Check also the linker script if there is
>one just in case...

After several days of investigation, I'm guessing it may be the "lot 
of sections which happen not to be located together." The linker 
script is the latest GNU libtool.

The code itself:
a) doesn't use templates
b) isn't "megatons" since individual C++ files weigh in at a few K.

Granted, I'm using bison and flex to generate some C++ code, but 
these are still fairly small in the scheme of things. On an 
individual basis, the object files are at most 50-100K.

So that would lead me to believe that the problem comes when linking 
a few several MB shared or static libraries together. Does this sound 
reasonable? Would these normally be in different sections as far as 
the linker is concerned? (I'm not an expert on object file formats.)

>You might also want to use the longcall attribute (I never tested it),
>from info gcc:

I'd obviously prefer to stay away from this if possible.

-Geoff


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Building Question

[Gabriel Paubert]

On Thu, 18 Nov 1999, Geoff Hutchison wrote:

> After several days of investigation, I'm guessing it may be the "lot 
> of sections which happen not to be located together." The linker 
> script is the latest GNU libtool.
> 
> The code itself:
> a) doesn't use templates
> b) isn't "megatons" since individual C++ files weigh in at a few K.
> 
> Granted, I'm using bison and flex to generate some C++ code, but 
> these are still fairly small in the scheme of things. On an 
> individual basis, the object files are at most 50-100K.
> 
> So that would lead me to believe that the problem comes when linking 
> a few several MB shared or static libraries together. Does this sound 
> reasonable? Would these normally be in different sections as far as 
> the linker is concerned? (I'm not an expert on object file formats.)

Have a look with objdump --head to all the files you are trying to link
and try to sum the .text and .data sizes. I've just discovered that the
.plt and .got sections get linked _after_ all the data sections and I
wonder why it is so. The linker replaces calls to shared library with
calls to the .plt section where it puts glue code to call the actual
function. You might need a different linker script in which you put the
plt before the data, for example by taking the default script
(/usr/lib/ldscripts/elf32ppclinux.x) and moving the 

  .plt   : { *(.plt) }

line just after the start of the data section (between the ALIGN statement
and the start of the .data group). I've checked that it did not break a
small program: it simply makes the executable slightly bigger (200 bytes
in my case) because the PLT is now in the middle of the file rather than
being truncated.

Anyway, this probably means that the application has a lot initialized
data (a few big arrays with some elements statically initialized could
cause it but it's a wild guess). The resulting executable will be huge in
any case (objdump --head will tell you how much you would have saved by
looking at the size of the plt). 


> 
> >You might also want to use the longcall attribute (I never tested it),
> >from info gcc:
> 
> I'd obviously prefer to stay away from this if possible.
> 

I understand.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Building Question

[Geoff Hutchison]

At 11:46 AM +0100 11/19/99, Gabriel Paubert wrote:
>Anyway, this probably means that the application has a lot initialized
>data (a few big arrays with some elements statically initialized could
>cause it but it's a wild guess). The resulting executable will be huge in
>any case (objdump --head will tell you how much you would have saved by
>looking at the size of the plt).

Thanks for your help. Fortunately it turned out to be much simpler. I 
saw someone suggest upgrading to a newer binutils for a similar 
problem and it helped. I'm now using the latest binutils RPM and 
don't seem to have any problems.

You are right that it has a lot of initialized data. It has one 
"defaults.cc" file with a large amount of static defaults. We'll 
probably discuss whether it's better to keep this or have a default 
config file load in before the user's config file.

Thanks to everyone for their help!
Cheers,

-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/