On 18 Mar 2022 11:43, Andrew Stubbs wrote: > Following your commit 96bc16f, merged yesterday, my amdgcn toolchain > fails to build. The Newlib built itself completes successfully, but > subsequent use of the library is broken. > > The problem seems to be related to the __malloc_lock function, but I > can't quite work out why. Here's the error message: > > ld: error: duplicate symbol: __malloc_lock > >>> defined at mlock.c:42 (..../newlib/libc/stdlib/mlock.c:42) > >>> libc_a-mlock.o:(__malloc_lock) in archive > ..../amdgcn-amdhsa/lib/libc.a > >>> defined at malloc_support.c:69 > (..../newlib/libc/machine/amdgcn/malloc_support.c:69) > >>> libc_a-malloc_support.o:(.text+0x1F8) in archive > ..../install/amdgcn-amdhsa/lib/libc.a > > ld: error: duplicate symbol: __malloc_unlock > >>> defined at malloc.h:138 (..../newlib/libc/include/malloc.h:138) > >>> libc_a-mlock.o:(__malloc_unlock) in archive > ..../amdgcn-amdhsa/lib/libc.a > >>> defined at malloc_support.c:96 > (..../newlib/libc/machine/amdgcn/malloc_support.c:96) > >>> libc_a-malloc_support.o:(.text+0x438) in archive > ..../install/amdgcn-amdhsa/lib/libc.a > collect2: error: ld returned 1 exit status > > (I should mention that the amdgcn port uses the LLVM binary utilities, > so the error messages look a little different to GNU ld. I've also > elided the long pathnames with "....".) looks like amdgcn doesn't have a GNU port at all, so i can't really repro this situation. i can't explain why it changed. it might be the overall ordering changed because of assumptions in the build ... > Previously only the machine-specific __malloc_lock was used, which is of > course the one I want. > > Should those functions be added differently now? i think you should always use the same name output if you want to override regardless of my recent change. the common code defines this in mlock.c, so i would expect you to put your machine overrides in a mlock.c file in your machine dir. this is how all the setjmp, mem*, and str* funcs all work. -mike