I am trying to build an application for ARM with the ARM GNU Toolchain (version 11.3 for now). To do so, I have a main program that I need to link to a static library foo that transitively depends on another static library bar.
Compiling the libraries and main program to ELF object files succeeds. But whenever I try to link any combination of the program and libraries together by running e.g. arm-none-eabi-gcc foo.o bar.o -o foobar.o I get fatal errors of the form:
c:/arm_toolchain_11/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: foo.o: in function `no symbol':
(.text.fooSome_Function+0x0): multiple definition of `no symbol'; foo.o:(.text.fooSome_OtherFunction+0x0): first defined here
...
c:/arm_toolchain_11/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: foo.o: .symtab local symbol at index 8830 (>= sh_info of 8046)
c:/arm_toolchain_11/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: foo.o: error adding symbols: bad value
collect2.exe: error: ld returned 1 exit status
I can't find anywhere what these kinds of linker errors generally tend to mean.
Running file on the object files returns the following:
# file foo.o
foo.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
# file bar.o
bar.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
You can see the results match.
Running readelf -sW on the files gives output ending like:
readelf: Warning: local symbol 8830 found at index >= .symtab's sh_info value of 8046
(with only the numbers differing). To me this indicates that GCC has somehow generated an invalid ELF file, but this seems very unlikely.
Finally, I am building this in MSYS2 on Windows.
Unfortunately, I cannot provide source code.
Is there anyone who could shed more light on this?
Thank you in advance!
Best regards,
Joshua
I discovered that the complex custom build system I was using to build the libraries was actually using Keil and not the GNU ARM Toolchain. If I compile and link everything with Keil's armclang I can avoid the problems and link everything together just fine. I think the problem is probably with Keil not implementing the exact same ARM C ABI as the GNU ARM toolchain (with the latter probably implementing it incorrectly seeing as ARM itself owns Keil). This would somewhat explain GCC/ld for ARM complaining about symbols in wrong places or having weird values.