3.4.0: picolibc build fails with duplicate malloc/free definitions

[arbrauns]

Describe the bug
A project that built correctly with Zephyr 3.3.0 now fails to link with 3.4.0:

/data/zephyr_sdk/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: modules/picolibc/libc.a(nano-malloc-malloc.c.obj): in function `malloc':
$PRJ_ROOT/modules/lib/picolibc/newlib/libc/stdlib/nano-mallocr.c:318: multiple definition of `malloc'; zephyr/lib/libc/common/liblib__libc__common.a(malloc.c.obj):$PRJ_ROOT/zephyr/lib/libc/common/source/stdlib/malloc.c:119: first defined here
/data/zephyr_sdk/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: modules/picolibc/libc.a(nano-malloc-free.c.obj): in function `free':
$PRJ_ROOT/modules/lib/picolibc/newlib/libc/stdlib/nano-mallocr.c:420: multiple definition of `free'; zephyr/lib/libc/common/liblib__libc__common.a(malloc.c.obj):$PRJ_ROOT/zephyr/lib/libc/common/source/stdlib/malloc.c:223: first defined here
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Probably relevant config options:

CONFIG_PICOLIBC=y
CONFIG_POSIX_API=y
CONFIG_PTHREAD_IPC=n

This seems superficially related to #57899, except that memalign is not mentioned.

I have not been able to reproduce this in a fresh project yet, but I can say that it happens both with and without CONFIG_PICOLIBC_USE_MODULE. What could cause the two definitions to conflict in my current project, but not in a fresh project (I checked, it also has malloc defined in both object files)?

Expected behavior
The build succeeds, using the common libc's definitions.

Impact
Unable to update to 3.4.0 at this time

Environment (please complete the following information):

• OS: Ubuntu 22.04
• Toolchain: Zephyr SDK 0.16.1
• Zephyr: 3.4.0

[arbrauns]

After trimming down the linker command line to a bare minimum, I found out that libapp.a was causing the issue. With some more digging and a bit of luck, I realized that I was using mallinfo(3) to check the heap usage; pulling in this symbol somehow also pulled in the malloc and free symbols from picolibc, causing the conflict. Commenting out the mallinfo call fixed the linker error.

It would have been great to have better visibility into what the hell the linker was doing here, but I got there in the end. Best of luck to anyone who finds themselves in a similar situation in the future.