My problem with the LD linker

[Nick Clifton]

Hi Marian,

> I can compile and link them either using:
> 
> * ARMCC/ARMLINK 2.2
> or
> * GCC(E) 4.6.3 and Binutils 2.21 or 2.27.

> The second option (GCC/Binutils) works for the first four projects, but
> the link phase (using ld) fails for the fifth project, saying:
> 
> ========================================================================
> arm-none-symbianelf-ld:
> \S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\release\ARMV5\urel\EEXE.LIB(uc_exe_.o)(.text+0x2):
> unresolvable R_ARM_THM_CALL relocation against symbol
> `_ZN4User9InvariantEv@@euser{000a0000}[100039e5].dll'


> I have a suspicion that the problem is in *size* of the resulting
> binary. The "Expert" project is rather big, several times bigger
> than the "Cleaner" project. But I do not understand ELF well enough
> to remedy the problem.

> Is it possible that some section of the resulting ELF file overflows?

Yes.  It may well be that the executable is so big that the distance from where
the Invariant function is being called and where it is being defined will not
fit into the Thumb function call instruction.

Several ideas come to mind:

  * Compile for ARM rather than THUMB - the ARM supports a larger address space.

  * Compile with GCC but link with ARMLINK.  (You did say that using ARMCC/ARMLINK works).

  * Compile with -ffunction-sections and -fdata-sections enabled and then link with -gc-sections enabled.
    This might help to reduce the code size by eliminating unused code/data.

  * Change the order of the object files on the linker command line so that uc_exe.o
    object is located closer to the system library that defines it.

  * Compile with -mlong-calls enabled so that function calls to far away destinations should work.

Cheers
  Nick