Linker error: error adding symbols: bad value with GNU ARM toolchain

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.

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,

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