Multiple Definition of malloc internals

[Lucien950]

Context

I first compile a static library (lib_stm32cube), which inclues heap_useNewlib.c, stm32 sources, etc. I then compile this static library with the rest of my sources together into the final executable. During this final compilation, I get the following linker errors:

C:/PROGRA~2/Arm GNU Toolchain arm-none-eabi/13.3 rel1/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: lib_stm32cube.a(heap_useNewlib.c.obj): in function `_sbrk_r':
PATH_TO/newlib_freertos_patch/heap_useNewlib.c:163: multiple definition of `_sbrk_r'; C:/PROGRA~2/Arm GNU Toolchain arm-none-eabi/13.3 rel1/bin/../lib/gcc/arm-none-eabi/13.3.1/thumb/v7e-m+fp/hard\libc.a(libc_a-sbrkr.o):sbrkr.c:(.text._sbrk_r+0x0): first defined here

C:/PROGRA~2/Arm GNU Toolchain arm-none-eabi/13.3 rel1/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: lib_stm32cube.a(heap_useNewlib.c.obj): in function `__malloc_lock':
PATH_TO/third_party/newlib_freertos_patch/heap_useNewlib.c:217:** multiple definition of `__malloc_lock'; C:/PROGRA~2/Arm GNU Toolchain arm-none-eabi/13.3 rel1/bin/../lib/gcc/arm-none-eabi/13.3.1/thumb/v7e-m+fp/hard\libc.a(libc_a-mlock.o):mlock.c:(.text.__malloc_lock+0x0): first defined here

C:/PROGRA~2/Arm GNU Toolchain arm-none-eabi/13.3 rel1/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: lib_stm32cube.a(heap_useNewlib.c.obj): in function `__malloc_unlock':
PATH_TO/third_party/newlib_freertos_patch/heap_useNewlib.c:227: multiple definition of `__malloc_unlock'; C:/PROGRA~2/Arm GNU Toolchain arm-none-eabi/13.3 rel1/bin/../lib/gcc/arm-none-eabi/13.3.1/thumb/v7e-m+fp/hard\libc.a(libc_a-mlock.o):mlock.c:(.text.__malloc_unlock+0x0): first defined here

[Lucien950]

Uses Windows 11, arm-none-eabi 13.3 rel1

[Lucien950]

Compiler Options (extracted by CMake)

Compile Options: -mthumb;-mthumb-interwork;-ffunction-sections;-fdata-sections;-fno-common;-fmessage-length=0;-Wl,--gc-sections;--specs=nano.specs;-Wall;-Werror;-Wextra;-pedantic;-Wdouble-promotion;-Wshadow;-Wundef;-fstack-usage;-Wconversion;-Wno-unused-variable;-Wno-unused-parameter;-Og;-g3;-mcpu=cortex-m4;-mfloat-abi=hard;-mfpu=fpv4-sp-d16

Compile Definitions: __weak=__attribute__((weak));__packed=__attribute__((__packed__));USE_HAL_DRIVER;ARM_MATH_MATRIX_CHECK;ARM_MATH_ROUNDING;ARM_MATH_CM4

Link Options: -Wl,-gc-sections,--print-memory-usage;-LPATH_TO/linker;--specs=nosys.specs;-mcpu=cortex-m4;-mfloat-abi=hard;-mfpu=fpv4-sp-d16;-Wl,-Map=PATH_TO/app.map;-Wl,-gc-sections,--print-memory-usage;-Wl,-T;PATH_TO/linker/stm32f412rgtx/stm32f412rgtx_app.ld

[DRNadler]

Edwin - The heap_useNewlib.c module REPLACES the buggy ST-provided code in the library. The linker takes standalone object files first, resolving the symbols in the object file, hence knowing not to pull in another copy for an unresolved symbol. If the linker finds multiple definitions in libraries it has a problem. Simplest is do not put heap_useNewlib object into a library! This is how a linker works...

[DRNadler]

Normal linker behavior, don't do that...

[Lucien950]

ok, I think that is very curious because I'm currently migrating from arm 10 to arm 13, and only during this migration have I discovered this error.

[Lucien950]

btw I am a beginner trying with limited understanding of the linker: Is this a issue specific to this scenario, where we're trying to override functions in standard library? Can I still put other code in a library, and will it behave more or less as if I compiled it directly with object files?

[Lucien950]

I have just removed it from the library, and moved it to be complied directly with the executable, and it's giving the exact same error. Looking at the compiler errors, it seems to be conflicting with functions in the C standard library, rather than code provided by STM... I'm not sure if that requires a different fix or what to do in this situation?

[DRNadler]

I'm sorry, I just don't have time right now to help you with this. You really need to go study: 1) how linkers work, and 2) how to debug your linker's actions to find out what you're missing...

[Lucien950]

Then I suppose in principle, should this source file be updating functions in libc? Or is this something I need to sort out in the linking?