Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
66 user(s) are online (54 user(s) are browsing Forums)

Members: 0
Guests: 66

more...

Support us!

Headlines

Report message:*
 

Re: Link problem (relocation truncated to fit)

Subject: Re: Link problem (relocation truncated to fit)
by alfkil on 2010/3/22 13:52:46

@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.

Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project