Link problem (relocation truncated to fit)

I'm trying to link an executable against library that is about 180MB large. I get these errors:

main.cpp(.text+0x2c): relocation truncated to fit: R_PPC_PLTREL24 against symbol 'std::string::size() const' defined in .plt section in /SDK/newlib/lib/crtbegin.o


I can't find much help on google, but one thing that people mention is, that it is a size problem, and that it could be related to -fPIC. I'm not so tough on code generation issues, but I do know, that -fPIC is something used for generating shared objects. My 180MB size library is a static library and is compiled without -fPIC or -fpic. My only go at the moment is to add -fPIC to the makefile and recompile the entire library... It's just, it takes more than 12 hours to compile, so I wanted to hear, if somebody had a better guess before wasting more time on it .

EDIT: I just noticed, that all the error msgs refer to crtbegin.o. Could it be a problem with crtbegin.o?

@alfkil
First, please read the SDK documentation regarding Amiga shared objects. You only use the -fPIC option and others when working with Amiga shared objects and this is documented in the SDK introduction.

As for the size theory, you would need to ask joerg as he is the newlib.library expert.

@ssolie

Thanks for the update on shared objects, I didn't read the docs since the SDK update.

Hmm... It seems, that -fPIC shouldn't be able to explain the error, although I _am_ in fact using some shared objects. But I'm also linking with at least 3 other static libraries, that haven't been compiled with -fPIC, and they don't display any such problems... (The code in the static libs cannot possibly ever be called from within the shared objects, so -fPIC is not a problem.)

I'll try and get a hold of J?rg, although my previous attempts at reaching him have all been in vain. I'm guessing he is dead busy...

EDIT: The -fPIC theory is definitely dead, because the people mentioning it refer to it as a "-fPIC versus -fpic issue". Amiga doesn't have -fpic at all. All other suggested solutions I have seen so far have - as far as I can see - been referring to system specific issues... Drats!

@alfkil

A PLTREL24 relocation is used to call a subroutine through a jump-slot in the .plt section. When linking with a shared object at run time the PLT (procedure linkage table) jump slots will be filled with vectors to the functions from the shared object.

PLTREL24 and the normal REL24 are mainly used for PPC "bl" instructions (used as a relative branch into a subroutine). The region which can be reached by such a branch is within a signed 26-bit value (the two least significant bits are always zero), which means +/- 32MB.

It seems that your program is so big that the distance to the .plt is not within 32 MB from your caller.

I don't know the linker script you are using, but for the PPC architecture the .plt is usually stored together with .bss sections, which means that the size of the data adds to the distance and the 32MB are easily exceeded...

@phx

Thanks for the info. It seems, that the issue have been fixed with later versions of gcc (4.4 or smth), but that doesn't help me a lot. Some people seem to think, that it can be avoided by compiling libraries as shared objects (that's pretty much what I'm trying to do at the moment) and possibly by compiling everything with -mlongcall. I have tried compiling the executable code with -mlongcall, and it _does_ seem to have an impact on the problem, but it doesn't remove it, it just "shifts" the problem to a new area. I'm guessing, that if I'm going to make it work, I'll need to compile EVERYTHING - including newlib - with -mlongcall, and that's a bit of a problem, since I don't even have access to the newlib sources...

Are the newlib sources available somewhere, or is it proprietary stuff? I've tried to contact J?rg, but he's probably too busy to answer. Also, I'm interested in knowing, if the adtools project on sourceforge is still active? It seems, that the last release was 20 months ago...?

This is a big shame, since my project was going so well until now...

@alfkil

With the risk of stating the obvious (or not knowing what I'm talking about): If the problem is that your (main) program is too big for the infrastructure of calling shared objects (as it works right now), why not make it smaller? Try to break out some more of your program into e.g. shared objects, so your main executable stays under those 32MB in size. Or, if much of all that space is taken up by data, try moving the data into dynamically allocated memory and - unless you generate it at runtime - load it from a separate file.

Best regards,

Niels

Another thing: if only some of the libraries are shared and the others are static, does that mean that some are clib2 and some are newlib? If so, then you'd better compile them all with the same run-time library.

@nbache

Yes, making it smaller would be a good solution. Problem is, I know so relatively little about the code I'm working with, so I wouldn't know where to start...

In the meantime, I managed to compile and link the code by means of adding -fPIC and -mlongcall to the compiler and recompiling all the Qt libs (the recompile took just about 20 hours...). Of course I can't know for sure, but I think the critical point here is the -mlongcall flag, that supposedly turns all the relative jumps and branches into absolute 32 bit ones. I'm building with only static objects now (no -use-dynld), so the shared objects V1 vs. V2 is not the issue. Also, I tried linking static only with my old objects (those without -fPIC and -mlongcall), and it still didn't work...

Problem with -mlongcall is, that the code gets slightly slower. Next thing I'm going to do is, that I'm going to link the Qt libs as all shared objects and see if I can get it working that way. As you said, Niels, I might have to split up the WebKit library in smaller parts to get it working.

Still my conclusion is, that if this is a general issue with large executables compiled with gcc on aos4, then there should be some information on how to solve it in the SDK docs, because other people are bound to get into the same problems as me in the future. Also, -mlongcall would not be a general solution unless ALL of the libraries used to link the code are compiled with this flag. As for my example, I'm just lucky, that recompiling Qt "solved" the problem.

@tonyw

Hmm... I'm not sure, I think I'm only using newlib libraries. Anyway, all the Amicygnix libraries are static, the rest are not.

But since I just managed to compile and link the whole thing with only static objects, and since the critical factor turns out the be the -mlongcall flag, mixing shared and static objects shouldn't be the issue.

I'm not sure wether -mlongcall versus no -mlongcall is going to be an issue, though...?

@alfkil

Quote:

Mixing static and shared libraries is an issue fullstop.

Best advice is to not do it. but if you must then make sure that non of your shared libs depend on any of the static ones, else it will crash at random.

Make sure that none of the static code going into your executable is -fPIC else when the executable size goes over a certain limit (aprox 18Mb can't remeber what the real number is) the -fPIC will require a PLT to make the jumps, but there is no PLT for the main exec only for shared libs, that will result in random and confusing crashies.

180Mb is real code size or code + debug?

As far as I can see if the majority of AmiCygnix libs are static, then an app using will have to be static too.

@broadblues

Quote:

But at the moment, I'm not using any shared objects at all, so _therefore_ it's not an issue.

180 MB is the real size of the library with no debug information. It contains nearly 1500 object files . The executable itself ends up being 80 MB in size.

Quote:

I know the issue is a bit tricky, but so far I have had no issues with using AmiCygnix in combination with shared objects, probably due to the fact (as you point out yourself) that the Amicygnix libraries never calls code in the shared objects. But yeah... Maybe I'll ask Edgar to do a .so version of the libraries, hope he has time .

@alfkil

Quote:

So your getting an error which seesm to imply dynamic linking (due to .plt reference but maybe it's a red herring) but your not using any dynamic libraries?

Can you post you link line options?

Quote:

WTF is it?


Quote:

The effects can be quite random, so just because you never had a problem doesn't mean you wont have a problem. And size matters. (and you seems to have quite alot of size).....

@broadblues

Quote:

Hmm... Yeah, that's strange. I'm not in the same place as my Sam right now, so I will have to check when I get back in a week or so.

EDIT: I forgot to mention, that I changed from linking dynamically to linking static - this was because Edgar provided me with an updated static freetype library, so I no longer needed to use the OS .so version. I don't remember the exact phrasing of the error messages, when I link static only. I'm quite sure, that they mention REL24 relocation truncated, but I'm not sure that they mention .plt at all. I will have to check...

Quote:

Well, nothing special, really... it's "just" the libQtWebKit module It seems to consist of appr. 1500 object files...