why is g++ relocation error linking only showing when listing objects explicitly?

why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

Hello,

I think this question belongs here and not on a general Unix mailing list, but I am not sure, so please forgive me if I am posting in the wrong place.  

I am getting the error 

"relocation truncated to fit: R_PPC_PLTREL24 against symbol ..." 

when using g++ to link about 2300 .o files into a single library, total size about 29MB, and -mlongcall does not help.


Curiously, this only happens when listing the files explicitly.   That is:

This doesn't work (24-bit relocation error)

>g++ -fPIC `<command to list object files>`


However, this works correctly (!!!???)

>echo `<the same command to list object files>` | xargs g++ -fPIC



What is going on here??

Thank you for any insight.

Mark

RE: why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

Hello,

I had posted the question below 5 days ago but there were no replys. At that time, it was a mere curiosity.  But now, what appeared to work then, actually does not work...  So now I am in trouble and I have more symptoms.

What is going on, and how do I get g++ linker to work here??

------------------------

Previous message:

(...)
when using g++ to link about 2300 .o files into a single library, total size about 29MB, and -mlongcall does not help.
(...)
This doesn't work (24-bit relocation error)

>g++ -fPIC `<command to list object files>`


However, this works correctly (!!!???)

>echo `<the same command to list object files>` | xargs g++ -fPIC

---------------------


Now:
Actually, the second version also does not work.  It does not give an error message, and there appears a big library.  BUT:   Some symbols are defined in some object files, but then become undefined in the resulting library!!!

If I decrease the number of object files to about 1200, the symbols in question vanish completely from the library!!!

Finally, if I decrease the number of object files further to about 800, the symbols in question are present in the library again, and this time defined as they should.




Please anybody knows what could be happening???


Mark

Re: why is g++ relocation error linking only showing when listing objects explicitly?

[Jonathan Wakely]

On 21 December 2012 09:38, Mark Galeck (CW) wrote:
> Hello,
>
> I had posted the question below 5 days ago but there were no replys. At that time, it was a mere curiosity.  But now, what appeared to work then, actually does not work...  So now I am in trouble and I have more symptoms.
>
> What is going on, and how do I get g++ linker to work here??
>
> ------------------------
>
> Previous message:
>
> (...)
> when using g++ to link about 2300 .o files into a single library, total size about 29MB, and -mlongcall does not help.
> (...)
> This doesn't work (24-bit relocation error)
>
>>g++ -fPIC `<command to list object files>`
>
>
> However, this works correctly (!!!???)
>
>>echo `<the same command to list object files>` | xargs g++ -fPIC
>
> ---------------------
>
>
> Now:
> Actually, the second version also does not work.  It does not give an error message, and there appears a big library.  BUT:   Some symbols are defined in some object files, but then become undefined in the resulting library!!!
>
> If I decrease the number of object files to about 1200, the symbols in question vanish completely from the library!!!
>
> Finally, if I decrease the number of object files further to about 800, the symbols in question are present in the library again, and this time defined as they should.
>
>
>
>
> Please anybody knows what could be happening???

I don't know what the relocation error is about, but it's not
surprising that using xargs doesn't help.

See the man page for xargs:

       The  command  line for command is built up until it reaches a
       system-defined limit (unless the -n and -L options are used).
       The specified command will be invoked as many times as neces‐
       sary to use up the list of input items.

So xargs is splitting up your command into:

g++ -fPIC <some of the object files>
g++ -fPIC <some more of the object files>
g++ -fPIC <the rest of the object files>

Each of these commands will produce an output file containing some of
the objects, then the next command will overwrite that file with a new
output file containing different objects.

Have you thought about adding the objects to an archive instead of
trying to link 2300 objects in a single command?

You can add new objects to an archive, so it wouldn't have to be done
in a single command.

RE: why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

OK.  Thank you Jonathan very much.  This was exactly right, xargs command line length limitation, the follow-up question not-on-topic. Sorry.


But now after learning from that, I am still having the 24-bit error relocation problem, when linking 2300 .o files into a lib, total size 29MB.

I guess it has something to do with 29MB being over 2^24 bytes?  


Jonathan says to add them one by one to an "archive".


I am really sorry for the naïve question, but I did RTFM, and I cannot find anything about "archiving".  


What I am doing right now is

>g++ --shared -fPIC -Wl,-soname,<.so file> "<command to list object files"

Does not work due to 24-bit relocation problem.



How do I replace it with "adding one by one to an archive"??  I am sorry, but I RTFMd and I don't find anything about that.  


Mark  

RE: why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

OK, I found out to use the GCC ar to make it into an "archive"

>ar -r foobar.a <object files>

This appears to work OK.  The archive is around 100MB large.


But I need an .so file instead, created as if by

>g++ -shared -fPIC -Wl,-soname,foobar.so -o foobar.so <object files>


How do I turn the foobar.a into the foobar.so  ???


I try by following the manual in the GNU ld linker, but when I just put foobar.a on the linker command line, the resulting .so is a few thousand bytes only.  Obviously no good.


How to turn foobar.a into foobar.so??


Thank you,

Mark

RE: why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

>How do I turn the foobar.a into the foobar.so  ???


OK, I got it

>g++ -Wl,--whole-archive foobar.a -o foobar.so



Except...  of course, again I get 

relocation truncated to fit: R_PPC_PLTREL24 against symbol...

BACK TO SQUARE ONE


yes foobar.a is 140MB.  What to do??



Thank you,

Mark

Re: why is g++ relocation error linking only showing when listing objects explicitly?

[Andrew Haley]

On 12/21/2012 02:36 PM, Mark Galeck (CW) wrote:
>> How do I turn the foobar.a into the foobar.so  ???
> 
> 
> OK, I got it
> 
>> g++ -Wl,--whole-archive foobar.a -o foobar.so
> 
> 
> 
> Except...  of course, again I get 
> 
> relocation truncated to fit: R_PPC_PLTREL24 against symbol...
> 
> BACK TO SQUARE ONE
> 
> 
> yes foobar.a is 140MB.  What to do??

I presume you're using "-mlongcall" everywhere.

We need to see the symbol and the place it's used.  You'll need
to use objdump --reloc.

Andrew.

RE: why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

OK.  Thank you for help

> ls -l foobar.a
-rw-r--r-- 1 mgaleck 140132266 Dec 21 06:10 foobar.a

>g++ -shared -fPIC -mlongcall -Wl,--whole-archive foobar.a

(...)
crtbeginS.o: In function `__do_global_dtors_aux':
crtstuff.c:(.text+0x54): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize@@GLIBC_2.1.3' defined in .text section in (...)/libc.so.6+8000

> objdump --reloc foobar.a | grep cxa_finalize
> objdump --reloc foobar.a | grep dtors_aux
>


??  what do you want me to call objdump --reloc with??

Re: why is g++ relocation error linking only showing when listing objects explicitly?

[Andrew Haley]

On 12/21/2012 02:57 PM, Mark Galeck (CW) wrote:
> OK.  Thank you for help
> 
>> ls -l foobar.a
> -rw-r--r-- 1 mgaleck 140132266 Dec 21 06:10 foobar.a
> 
>> g++ -shared -fPIC -mlongcall -Wl,--whole-archive foobar.a
> 
> (...)
> crtbeginS.o: In function `__do_global_dtors_aux':
> crtstuff.c:(.text+0x54): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize@@GLIBC_2.1.3' defined in .text section in (...)/libc.so.6+8000
> 
>> objdump --reloc foobar.a | grep cxa_finalize
>> objdump --reloc foobar.a | grep dtors_aux
>>
> 
> 
> ??  what do you want me to call objdump --reloc with??

Aha!  The error is in crtbeginS.o.  This is important: it is not one
of the files you compiled.  Therefore, no matter what you do with
-mlongcall", it won't help.  It may be that recompiling crtbeginS.o with

-mlongcall" would help, but we'd need a PPC export to confirm that.

It may be easier simply to split the shared library.

Andrew.

RE: why is g++ relocation error linking only showing when listing objects explicitly?

[Mark Galeck (CW)]

>Aha!  The error is in crtbeginS.o.  This is important: it is not one of the files you compiled.  Therefore, no matter what you do with -mlongcall", it won't help.  It may be that recompiling crtbeginS.o with

-mlongcall" would help, but we'd need a PPC export to confirm that.

Out of the question... :(   can't recompile any system stuff.  

>It may be easier simply to split the shared library.


Also out of the question I am afraid.  Has to be one lib.



Well, the thing is, there is one particular order of the .o files, that seems to work.  It's just that, I am using a different order.  I don't want to use that other order, besides, it's like hit-and-miss, one day (perhaps tomorrow), someone will add another object and it won't work any more.  

It's a pain, huge pain, for me to use that other order.  But I guess I won't have a choice.  

Re: why is g++ relocation error linking only showing when listing objects explicitly?

[Andrew Haley]

On 12/21/2012 03:10 PM, Mark Galeck (CW) wrote:
>> Aha!  The error is in crtbeginS.o.  This is important: it is not one of the files you compiled.  Therefore, no matter what you do with -mlongcall", it won't help.  It may be that recompiling crtbeginS.o with
> 
> -mlongcall" would help, but we'd need a PPC export to confirm that.
> 
> Out of the question... :(   can't recompile any system stuff.  
> 
>> It may be easier simply to split the shared library.
> 
> Also out of the question I am afraid.  Has to be one lib.

Well, that's the trouble.  There are a couple of correct ways to fix
your problem, but you reject them because you aren't allowed.

> Well, the thing is, there is one particular order of the .o files,
> that seems to work.  It's just that, I am using a different order.
> I don't want to use that other order, besides, it's like
> hit-and-miss, one day (perhaps tomorrow), someone will add another
> object and it won't work any more.

Exactly.  That's why it's the wrong thing to do.

Andrew.