This is the mail archive of the
mailing list for the binutils project.
Re: My problem with the LD linker
thank you for your suggestions.
ARMLINK 2.2 will not work with objects compiled by GCC 4.6.3, complains
about invalid object file.
I was nevertheless lucky anyway, though it is embarrasing to admit. My
LD of 2.27 version works! The trouble was that when I substituted LD
2.21 for the newer 2.27, I did not notice that another copy of the
older, faulty 2.21 lingered somewhere on the disk, and unfortunately on
the system path.
As soon as I discovered it and got rid of it, things got better. I can
link my EXE now. It is only about 9 MB big, not a big deal.
Thank you for your help.
Dne 22.2.2017 v 13:07 Nick Clifton napsal(a):
> Hi Marian,
>> I can compile and link them either using:
>> * ARMCC/ARMLINK 2.2
>> * 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:
>> unresolvable R_ARM_THM_CALL relocation against symbol
>> 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.