2

When I try to compile a trivial example test.c

int main () {
  return 0;
}

for a cortex m7 target with hard float ABI by using the following invocation

arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs test.c

I get this error:

/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: a.out uses VFP register arguments, /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libc.a(lib_a-atexit.o) does not
[snip]
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libnosys.a(_exit.o)
collect2: error: ld returned 1 exit status

So the issue is that gcc is linking to the wrong libc.a. If I use the argument print-multi-directory, it would appear that my version of arm-none-eabi-gcc should support this architecture:

$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs --print-multi-directory
thumb/v7e-m/fpv5/hard

And I can list the different versions of libc.a that are provided by arm-none-eabi-gcc:

$ find /usr/lib/arm-none-eabi/ -name libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/libc.a
/usr/lib/arm-none-eabi/newlib/armv6-m/libc.a
/usr/lib/arm-none-eabi/newlib/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/thumb/libc.a
/usr/lib/arm-none-eabi/newlib/armv7-m/libc.a

So it looks like there is a version of libc.a compiled for my desired architecture, but gcc isn't linking against it. How can I get gcc to link against the correct version of libc.a?

I'm using arm-none-eabi-gcc version 6.3.1 provided by the gcc-arm-none-eabi package for Ubuntu 18.04.

artless noise
  • 21,212
  • 6
  • 68
  • 105
awelkie
  • 2,422
  • 1
  • 22
  • 32
  • Possible duplicate of [ARM compilation error, VFP registered used by executable, not object file](https://stackoverflow.com/questions/9753749/arm-compilation-error-vfp-registered-used-by-executable-not-object-file) – KamilCuk Jan 21 '19 at 14:30
  • 2
    nosys is configured with soft float abi. You need to recompile newlib with hard float abi for your target cpu. Or recompile without `-specs=nosys.specs` – KamilCuk Jan 21 '19 at 14:31
  • This problem persists without `-specs=nosys.specs`. – awelkie Jan 21 '19 at 15:15
  • And based on the existence of `/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/libc.a`, it seems that there is a version of newlib compiled for hard float abi. I'm just confused why gcc is trying to link against the soft float version. – awelkie Jan 21 '19 at 15:17
  • 1
    hm, good point, but he links with different file `/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libc.a`. [gcc 7.3 on godbolt](https://godbolt.org/z/le1Why) just compiles... Maybe try something along `-nostdlib` and pass the proper libc.a along the command line? Looks like a related gcc bug I found, see https://github.com/ARMmbed/mbed-os/issues/7852 – KamilCuk Jan 21 '19 at 16:15
  • 1
    Don't use `-mcpu=cortex-m7`, use `-march=armv7e-m` to pick the right libraries. This is similar to the other question, but it is not a duplicate in my opinion. I imagine the multi-lib matching has improved over time to explain godbolt's success. – artless noise Jan 21 '19 at 17:43
  • Related: [Difference between hard and soft float (for ARM)](https://stackoverflow.com/questions/3321468/whats-the-difference-between-hard-and-soft-floating-point-numbers); also not a duplicate but very similar. There are lots of different root causes of this error. – artless noise Jan 21 '19 at 17:53
  • There is nothing "trivial" whatsoever with a C library, newlib or other they are massive and painful. – old_timer Jan 21 '19 at 17:59
  • when you build newlib what command line does it use for the libraries and what happened when you tried that? newlib is not part of the gnu toolchain you want a specific library you adjust your environment and/or paths and/or command line to point at it. if it is a case of none of them work then try using the command line used when they build at least one of them. – old_timer Jan 21 '19 at 18:01
  • I think the issue I was experiencing is documented here: https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1767223 (linked from @kamil's comment). The solution was to download a newer version of gcc. – awelkie Jan 22 '19 at 10:04

0 Answers0