Conflicting CPU architectures 1/13 when compiling for cortex M4

Question

I used to compile my microcontroller code with arm-none-eabi-gcc/arm-none-eabi-g++ and everything worked fine. I use the homebrew Cask gcc-arm-embedded on Mac. Yesterday I updated it and now I get these error messages for every object file at the link stage when I compile for a Cortex M4 architecture (compiles fine with M3):

/usr/local/Caskroom/gcc-arm-embedded/6-2017-q1-update/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: error: anobjectfile.o: Conflicting CPU architectures 1/13
/usr/local/Caskroom/gcc-arm-embedded/6-2017-q1-update/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file example.o

When looking at the content everything looks fine:

$ arm-none-eabi-readelf -A example.o
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "Cortex-M4"
  Tag_CPU_arch: v7E-M
  Tag_CPU_arch_profile: Microcontroller
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv4-D16
  Tag_ABI_PCS_wchar_t: 2
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: small
  Tag_ABI_HardFP_use: SP only
  Tag_ABI_VFP_args: VFP registers
  Tag_ABI_optimization_goals: Aggressive Size
  Tag_CPU_unaligned_access: v6

Here is a command line for compiling a C file:

arm-none-eabi-gcc -ffunction-sections -Wall -Werror -I… -std=c99 -DBOARD_DISCOVERY_F429 
  -DPORT_CPU=stm32f429 -DPORT_CPU_FAMILY=arm -DPORT_CPU_FAMILY_SUBFAMILY=CM4F 
  -DPORT_CPU_FLAVOR=stm32f4xx -g -Os -DNDEBUG -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 
  -mfloat-abi=hard -fno-math-errno -mtune=cortex-m4 -D__thumb2__=1 -march=armv7e-m -mthumb 
  -DUSE_STDPERIPH_DRIVER -DSTM32F429_439xx -mapcs-frame -mno-sched-prolog -fshort-wchar 
  -D__LITTLE_ENDIAN -ffunction-sections -fdata-sections -fno-builtin-malloc 
  -fno-builtin-realloc -fno-builtin-free -fno-strict-aliasing -DTARGET_LITTLE_ENDIAN 
  -DHSE_VALUE=8000000 -DPLL_M=8 -g -c -o example.o example.c

For a C++ file:

arm-none-eabi-g++ -ffunction-sections -Wall -Werror -I… -fno-exceptions -fno-rtti 
  -std=c++11 -DBOARD_DISCOVERY_F429 -DPORT_CPU=stm32f429 -DPORT_CPU_FAMILY=arm 
  -DPORT_CPU_FAMILY_SUBFAMILY=CM4F -DPORT_CPU_FLAVOR=stm32f4xx -g -Os -DNDEBUG 
  -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fno-math-errno -mtune=cortex-m4 
  -D__thumb2__=1 -march=armv7e-m -mthumb -DUSE_STDPERIPH_DRIVER -DSTM32F429_439xx 
  -mapcs-frame -mno-sched-prolog -fshort-wchar -D__LITTLE_ENDIAN -ffunction-sections 
  -fdata-sections -fno-builtin-malloc -fno-builtin-realloc -fno-builtin-free 
  -fno-strict-aliasing -DTARGET_LITTLE_ENDIAN -DHSE_VALUE=8000000 -DPLL_M=8 -g -c 
  -o example.o example.cpp

And the link:

arm-none-eabi-gcc -Wl,--gc-sections -Wl,-Map=executable.map -o executable.elf executable.o 
  file1.o file2.o … -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fno-math-errno 
  -mtune=cortex-m4 -march=armv7e-m -mthumb -Wl,--no-wchar-size-warning -g 
  -T…/stm32f40x.ld -specs=…/specs -Wl,--start-group …/lib1.a …/lib2.a …  -Wl,--end-group

Looking at multi-lib:

$ arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
hard;@mfloat-abi=hard
thumb/v6-m;@mthumb@march=armv6s-m
thumb/v7-m;@mthumb@march=armv7-m
thumb/v7e-m;@mthumb@march=armv7e-m
thumb/v7-ar;@mthumb@march=armv7
thumb/v8-m.base;@mthumb@march=armv8-m.base
thumb/v8-m.main;@mthumb@march=armv8-m.main
thumb/v7e-m/fpv4-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5/hard;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=hard
thumb/v7-ar/fpv3/softfp;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp
thumb/v7-ar/fpv3/hard;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5-sp/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5-sp/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=hard

There is a configuration matching my parameters:

thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard

Anyone knows what's wrong in my configuration?

Looks like you are headed down the right path on this, gnu puts info in the elf file and will at times not link them if that info doesnt match. you can start by using file or readelf to see what each elf object or library says as far as architecture (might not be enough information). can look at your working project in the same way. I assume you are building your files with the same/similar options as the library was built? — old_timer
Yes, I compile the lib with the same flags. I wrote the libs as well and used it in many projects before. I'll look at your suggestion and keep you updated. Thanks! — Tom
again you appear to be looking in the right places, likely some subtle thing that has upset the linker. — old_timer

Tom Tom · Accepted Answer · 2017-05-25T06:49:25

A colleague found the issue. For some reasons we needed to change the compiler specs. For this we added this to the link commandline: -specs=…/specs

We generated the specs file with the following command arm-none-eabi-gcc -c foo.c -dumpspecs

The thing is that the new version of the compiler had new specs, so we had to generate them again, which solved the issue.

Conflicting CPU architectures 1/13 when compiling for cortex M4

1 Answers