Hello everyone!
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.
foo
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:
arm-none-eabi-gcc foo.o bar.o -o foobar.o
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
# 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 -sW
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.