From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id F33E0385840C for ; Sun, 20 Mar 2022 01:19:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F33E0385840C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id A64E03437BD; Sun, 20 Mar 2022 01:19:54 +0000 (UTC) Date: Sat, 19 Mar 2022 21:20:04 -0400 From: Mike Frysinger To: Andrew Stubbs Cc: Newlib Subject: Re: amdgcn build failure Message-ID: Mail-Followup-To: Andrew Stubbs , Newlib References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UoAWH96aje9phRxY" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2022 01:20:00 -0000 --UoAWH96aje9phRxY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 18 Mar 2022 11:43, Andrew Stubbs wrote: > Following your commit 96bc16f, merged yesterday, my amdgcn toolchain=20 > fails to build. The Newlib built itself completes successfully, but=20 > subsequent use of the library is broken. >=20 > The problem seems to be related to the __malloc_lock function, but I=20 > can't quite work out why. Here's the error message: >=20 > 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=20 > ..../amdgcn-amdhsa/lib/libc.a > >>> defined at malloc_support.c:69=20 > (..../newlib/libc/machine/amdgcn/malloc_support.c:69) > >>> libc_a-malloc_support.o:(.text+0x1F8) in archive=20 > ..../install/amdgcn-amdhsa/lib/libc.a >=20 > 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=20 > ..../amdgcn-amdhsa/lib/libc.a > >>> defined at malloc_support.c:96=20 > (..../newlib/libc/machine/amdgcn/malloc_support.c:96) > >>> libc_a-malloc_support.o:(.text+0x438) in archive=20 > ..../install/amdgcn-amdhsa/lib/libc.a > collect2: error: ld returned 1 exit status >=20 > (I should mention that the amdgcn port uses the LLVM binary utilities,=20 > so the error messages look a little different to GNU ld. I've also=20 > 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= =20 > course the one I want. >=20 > 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 --UoAWH96aje9phRxY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmI2gUQACgkQQWM7n+g3 9YHeFQ//XLsMo4TfOYT97LXUpGgZ4LxLgSptrUNswMeKY8VAtM3VWYlhtKu2gv36 kDi7BQFxk44bCgLp1DDKLEUxXNdt47d/J/lCIc1ZricQsQs3n+tcMLbqwfYT11dg OzHB4YBjJ9A9QSDNath5jca7I4FfA2buECrhHfN5BUy1ffANr7IqSP3SrXESrY/M +zFWxCkxfWGwYS41JIa20NElWsKMXKBowKKlq3/+9ocTYHXte+vk6//TdMMy1Ywr PHp9cRI2eNdTM736N4BjRq/aqAo04GtIE1/7UfHoe4kKKbn3gYKUjcTYFxvLAZPF 34yjqyUtsNZxT5z4rvMTkyfCajR74D6U2bd6skPep23mcQ/aW2n2bzVvA9PHtkKD T02jEu6GPpS7X+T17w4YCJIqsppinNcFX90sPxXXRbePdmyJxgfpwIGDG27yXfLe P+WuqfZZgxMhexv88bCvwGVgCkZHQj4zFyJsXUbj1ZGs6WHNXNaNd2/f0e2K4VF2 6RuDyDpCnfZNbPxhUFouJSstMkuVvTrNFaVIKSKUUOhRB3ULop74356yD36brFnp V/fCuMsrvtBaKRMMw3xn1pJMfeyRxeV0KdZY5PmEIvApi8a7yuUNKd7GJ4atr7lM Ggc6Ni4zgmvLwxLeFHmxqaXIjhYoIjKfB54GrC6eDGyICXwVNTg= =G9iS -----END PGP SIGNATURE----- --UoAWH96aje9phRxY--