amdgcn build failure

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20220319/ddc544d4/attachment.sig>