From owner-freebsd-ports@freebsd.org Thu Jul 23 20:20:50 2020 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 79076362EA8 for ; Thu, 23 Jul 2020 20:20:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BCNxr4lbsz46XY for ; Thu, 23 Jul 2020 20:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: LusplPAVM1nBhCytP2vnGiuN2xvn4S1pA0Zhu8AMN0t7ZrsR.sfJ4a0BSANM65Q TVXUT1eeei6wdihIIBa2dhVem8TDSlICW.00mVRn.tyODNz6MnffhHQLlrZGl1T5dxQJHlpc026b 0I3jDvuAV5wWMF_C1.Kmpll.0zUqBBMsVQzIBBJvvmnI6KAxvWKAjlnA7t32P.8OHQKYnymEiKo6 ooBRmJYPiXFr3Al7m1l32drdFNv8ssGsyDKnyY.n5tBFFlUu61tdvXnVGXi3FnQSB89zRMMudD3q MF9w5BJAVvUJ0alEhwJhYNSvj2QFN6kAU9Z4a0tr_QJyTQ.3N77hVexwE4IxV9zu8jtktVqMxgJE GJkt6fWuog5cZ.hHvHC3vzFgSddqpdf4alztvLa9oXJHLakVcFN_W3P4r8Jz3OrSE8vQvTp6KEs1 EtJwk.RA_HAS2SGeAV67sntkbjlVMFJDeKw5Yoyd5VcQViuEwzSfO0Vfve2Fmy1EatGuMAd5Y6Zt jQxbCAma18pG9cvVaMZTHgC5abTG.TgxexcD6Bw49NUzb_hqTfiXYU_MyKd8TB1Wx7peRtvefF0a HQkcc1D20j7AM4f3csrXdX7w6uQ23PhgMftRTrNqZLIH4gk9QGO0wV60BAdsfoic1cWF3gr6_A.q 1LIlGjLUxjRY0R0MmvrG.IcneLzsAv6BwFURPHJzPad2pKhykgWVqUbRUJlLvE_76kJO_TWEDEC3 v7FJLxtoJciFnrCqa6_hz9kFvyHFrIQVtbDL4eTFsA6D1_yrnTTaDcFyOVIzCDbuW_YamFg_U_rY lJyAp2MbY8KfeA7gS5KfVknUG4ayZwpsyOvGg1OkLFKBZoWBCGz4_OdauAl4HyrKLCinfYHwidRF S7fEpjiG7HcyQBZwWh_IiXLu0l6Dl6ZmkgpoNT3Q_2Y8XUSzzQUJO49vzV_mgO8RndsM4m_yHtnp hsZ5BLyrfyTRcASNhsbsaeRKi03.xDZ_a5qvEIFLpGEMk8YTjghPf3gpGGhQqSYzGaF23yqFrFYO EJH960ZUmUnSariyQQayb2zlg9QbcELgKhWOtV4kYGQ8mNH_E4zh0lldIqqChDHyR5u_TWI6ckut CcC.hIoLIewFPxwkgyTfpXTxMh09vbXxmyRj3PoEfV0Oz0tkvD99tr2c1uzcyMFYJtxWZYCslzTc xU_8Q43pCTNRFxiqlf4SBjrei66nGhqilA9npa5_dJfk.VRwncYeEFHdGwfdP8mKrHWiTrdX4vYr GScqSmLCZ4mJ3MLcKtxYYWfDwlUOThx67FpPP6JU_lpVNXdALJedBpLL7IsBXT4.KQgUMdSEaxRD FQ9cvRoCjFdMOMBOsMVq4D8y37lkskSw352BdiMBs4UJC30rnTtwgaHB9WxFY4SnP9V2GW8wnIhk yPAUKokYGHx0lj6lgUMyFiVgH0Yc.GNKQmJ3dCEeYqKNjTwXGYZ.ignLLS5BiwG5CbHwvSZrA.aQ _Ww-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Jul 2020 20:20:47 +0000 Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c3c814bed1bcedbd221c8c32adf7f6b8; Thu, 23 Jul 2020 20:20:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8) From: Mark Millard In-Reply-To: Date: Thu, 23 Jul 2020 13:20:43 -0700 Cc: FreeBSD ports Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C21ED1D-BDE8-4E28-A56E-76A670B66ED6@yahoo.com> To: Jan Beich , "pkubaj@freebsd.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4BCNxr4lbsz46XY X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.32 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.76)[-0.760]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.025]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.04)[-1.038]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:20:50 -0000 On 2020-Jul-23, at 09:25, Mark Millard wrote: >=20 > On 2020-Jul-22, at 21:02, Mark Millard wrote: >=20 >> On 2020-Jul-22, at 17:16, Mark Millard wrote: >>=20 >>> On 2020-Jul-22, at 14:11, Jan Beich wrote: >>>=20 >>>> Mark Millard via freebsd-ppc writes: >>>>=20 >>>>> ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin = function '__sync_add_and_fetch_8' >>>>> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val) >>>>> ^ >>>>> ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a = builtin with type 'long long (volatile long long *, long long, ...)' >>>>> ../src/util/u_atomic.c:38:1: error: definition of builtin function = '__sync_add_and_fetch_8' >>>>> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val) >>>>> ^ >>>>> ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin = function '__sync_sub_and_fetch_8' >>>>> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val) >>>>> ^ >>>>> ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a = builtin with type 'long long (volatile long long *, long long, ...)' >>>>> ../src/util/u_atomic.c:51:1: error: definition of builtin function = '__sync_sub_and_fetch_8' >>>>> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val) >>>>> ^ >>>>> ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin = function '__sync_val_compare_and_swap_8' >>>>> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, = uint64_t newval) >>>>> ^ >>>>> ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' = is a builtin with type 'long long (volatile long long *, long long, long = long, ...)' >>>>> ../src/util/u_atomic.c:64:1: error: definition of builtin function = '__sync_val_compare_and_swap_8' >>>>> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, = uint64_t newval) >>>>> ^ >>>>> 6 errors generated. >>>>=20 >>>> Try replacing files/patch-i386 with = https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464 >>>> On i386 (clang) one can sometimes avoid -latomic by bumping -march >>>> (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) = probably >>>> can't use __sync* with 64-bit types without -latomic, making Meson >>>> define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c >>>=20 >>> The context was head (so system-clang instead of >>> gcc 4.2.1). But, looking in the logs, it seems to >>> have used an odd mix of system-clang and devel/lvm80 >>> materials: >>>=20 >>> . . . >>> Project name: mesa >>> Project version: 19.0.8 >>> Using 'CC' from environment with value: 'cc' >>> Using 'CFLAGS' from environment with value: '-O2 -pipe -g = -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' = -Wl,-rpath=3D/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> Using 'CXX' from environment with value: 'c++' >>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g = -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' = -Wl,-rpath=3D/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> Using 'CC' from environment with value: 'cc' >>> Using 'CFLAGS' from environment with value: '-O2 -pipe -g = -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' = -Wl,-rpath=3D/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang = version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d)") >>> C linker for the host machine: cc ld.lld 10.0.1 >>> Using 'CXX' from environment with value: 'c++' >>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g = -fstack-protector-strong -fno-strict-aliasing ' >>> Using 'LDFLAGS' from environment with value: ' = -Wl,-rpath=3D/usr/local/llvm80/lib -fstack-protector-strong ' >>> Using 'CPPFLAGS' from environment with value: '' >>> C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang = version 10.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.1-rc2-0-g77d76b71d7d)") >>> C++ linker for the host machine: c++ ld.lld 10.0.1 >>> Host machine cpu family: ppc >>> Host machine cpu: powerpc >>> . . . >>> llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1 >>> Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, = bitwriter, engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1 >>> . . . >>> cc . . . -DHAVE_LLVM=3D0x0800 -DMESA_LLVM_VERSION_PATCH=3D1 . . . -c = ../src/util/u_atomic.c >>> . . . >>>=20 >>>=20 >>> The system-clang devel/llvm80 mix seems to be at >>> least declaring __sync_add_and_fetch_8 , >>> __sync_sub_and_fetch_8 , and >>> __sync_val_compare_and_swap_8 as builtin, >>> possibly implicitly. >>>=20 >>> At this point I'm unclear if: >>>=20 >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464 >>>=20 >>> is relevant. The system-clang and devel/llvm80 mix >>> just does not seem the right kind of thing to be >>> doing in the build. >>>=20 >>=20 >> I'm not sure how analogous gecko is but I'll note >> that /usr/ports/Mk/bsd.gecko.mk has the related >> and additional logic: >>=20 >> BUILD_DEPENDS+=3D llvm${LLVM_DEFAULT}>0:devel/llvm${LLVM_DEFAULT} \ >> . . . >>=20 >> MOZ_EXPORT+=3D ${CONFIGURE_ENV} \ >> LLVM_CONFIG=3Dllvm-config${LLVM_DEFAULT} = \ >> . . . >>=20 >> . if ${CC} =3D=3D cc && ${CXX} =3D=3D c++ && = exists(/usr/lib/libc++.so) >> BUILD_DEPENDS+=3D = ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} >> CPP=3D ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} >> CC=3D = ${LOCALBASE}/bin/clang${LLVM_DEFAULT} >> CXX=3D ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} >> USES:=3D ${USES:Ncompiler\:*} # XXX avoid warnings >> . endif >>=20 >> This last block of code appears to be forcing it to use >> the matching devel/llvm* port's llvm/clang materials >> under some conditions (instead of an odd mix with system >> clang). >>=20 >=20 > Given that older llvm's have tended to have code generation or > other problems for 32-bit powerpc and powerpc64 I decided to > experiment with: >=20 > # svnlite diff /usr/ports/graphics/mesa-dri/ | more > Index: /usr/ports/graphics/mesa-dri/Makefile.common > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/graphics/mesa-dri/Makefile.common (revision = 542111) > +++ /usr/ports/graphics/mesa-dri/Makefile.common (working copy) > @@ -85,8 +85,8 @@ >=20 > .include >=20 > -.if ${ARCH} =3D=3D powerpc64 > -LLVM_DEFAULT=3D 90 > +.if ${ARCH} =3D=3D powerpc64 || ${ARCH} =3D=3D powerpc > +LLVM_DEFAULT=3D 10 > .elif ${LLVM_DEFAULT:C/[1-5]./&0/:S,-devel,990,} >=3D 90 > LLVM_DEFAULT=3D 80 > .endif > @@ -97,6 +97,13 @@ > MESON_ARGS+=3D -Dllvm=3Dfalse > .else > BUILD_DEPENDS+=3D = llvm${LLVM_DEFAULT}>=3D3.9.0_4:devel/llvm${LLVM_DEFAULT} > +. if ${CC} =3D=3D cc && ${CXX} =3D=3D c++ && = exists(/usr/lib/libc++.so) > +BUILD_DEPENDS+=3D = ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} > +CPP=3D ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} > +CC=3D ${LOCALBASE}/bin/clang${LLVM_DEFAULT} > +CXX=3D ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} > +USES:=3D ${USES:Ncompiler\:*} # XXX avoid warnings > +. endif > .if ${COMPONENT} !=3D libs > RUN_DEPENDS+=3D = llvm${LLVM_DEFAULT}>=3D3.9.0_4:devel/llvm${LLVM_DEFAULT} > .endif >=20 >=20 > Turns out that mesa-dri uses = /usr/local/llvm10/include/llvm/ADT/StringRef.h > and that in llvm10 that code is c++14 (or later) based, while mesa-dri = builds > via using -std=3Dc++11 . So clang++10 rejects the likes of: >=20 > /usr/local/llvm10/include/llvm/ADT/STLExtras.h:559:49: error: no = template named 'index_sequence' in namespace 'std' > template value_type deref(std::index_sequence) = const { >=20 >=20 > But /usr/local/bin/clang++10 and such was used, matching the = LLVM_DEFAULT > I'd set. So the: >=20 > +. if ${CC} =3D=3D cc && ${CXX} =3D=3D c++ && = exists(/usr/lib/libc++.so) > +BUILD_DEPENDS+=3D = ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} > +CPP=3D ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} > +CC=3D ${LOCALBASE}/bin/clang${LLVM_DEFAULT} > +CXX=3D ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} > +USES:=3D ${USES:Ncompiler\:*} # XXX avoid warnings > +. endif >=20 > may be reasonable. >=20 Switching to the atomics issue . . . mesa-19.0.8/src/util/u_atomic.h has: /* Favor OS-provided implementations. * * Where no OS-provided implementation is available, fall back to * locally coded assembly, compiler intrinsic or ultimately a * mutex-based implementation. */ #if defined(__sun) #define PIPE_ATOMIC_OS_SOLARIS #elif defined(_MSC_VER) #define PIPE_ATOMIC_MSVC_INTRINSIC #elif defined(__GNUC__) #define PIPE_ATOMIC_GCC_INTRINSIC #else #error "Unsupported platform" #endif So, unless PIPE_ATOMIC_GCC_INTRINSIC covers everything needed, 32-bit powerpc is not going to work unless this area is extended with more options or PIPE_ATOMIC_GCC_INTRINSIC covers more than it now does. There are no 64-bit operations available for p_atomic_set, p_atomic_read, p_atomic_dec_zero, p_atomic_inc, p_atomic_dec, p_atomic_add, p_atomic_inc_return, p_atomic_dec_return, and p_atomic_xchg to use as far as I can tell: __atomic_??? ones are not available. __atomic_??? would not cover p_atomic_cmpxchg anyway: that still has to have __sync_val_compare_and_swap . (See the content of mesa-19.0.8/src/util/u_atomic.h .) As for __sync_??? use for 64-bit operations: There are no __sync_??? for p_atomic_set or for p_atomic_read: it is presumed that (*(_v) =3D (_i)) and (*(_v)) are directly atomic but they would not be for 32-bit powerpc as far as I can tell. (See the content of mesa-19.0.8/src/util/u_atomic.h .) clang rejects the attempts to define the __sync_??? builtins (for 64 bit), at least via the notation currently used in u_atomic.c . It looks to me like 32-bit powerpc may be an example that should be: #error "Unsupported platform" (i.e., not even defining PIPE_ATOMIC_GCC_INTRINSIC), at least until significant more work was done to provide the __atomic_??? and __sync_val_compare_and_swap for 64-bit operations. (This gives coverage of p_atomic_set and p_atomic_read via USE_GCC_ATOMIC_BUILTINS in the u_atomics.h header as it is now. The __sync_??? alternative does not.) So maybe a BROKEN_powerpc=3D in the Makefile? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)