From owner-freebsd-ports@freebsd.org Thu Jul 23 04:02:11 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 62AC236F945 for ; Thu, 23 Jul 2020 04:02:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4BBzDf3XYLz41ky for ; Thu, 23 Jul 2020 04:02:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3DT_5fsVM1mK.d6DtD9v3nBW2uODItQ6dIC00.hEzxqUiBhpPimmVfPqmuFkYkS dMlELN.ano.Z9OVoSZQ3tgwzhK45QaSSWkpHCrOcAOWK9.s.Waxn430dgqTjSpEmr2f1ELZQtUaC ZekyhunchM8.rPFDQeDCo3CJ.9UZYOwVp.UeSmT840wEvsE1He7.Sa2Uv0oxiWbfyHsstum0FcA6 PFyvAQ6CqHmdU5U6B91WC7xjWtIirmLwHJ3QsH0RnPEkNFtJ_A22Ri7V0avUNfGEi3CTAxkGkIO5 8kwmF3pUb7697cgRt8sSUHzUQk9VAk2DhG.8xHtdw7C5QZrGoCEkkaczv3.cs_ABcXqJcPJS1.YY jNmr9z61fVjG05qqOChAQwJH97EeK2Yb2fb.eQU5droWTYWs8Ck04H0fX_S0Te4lGfdnW6LpiM2S KizX6A8NAxIMBKipdzuw6MIJnLGsQPbPPyFdgl0uQqP320Vc868dVaw1u5l8CykfWaeFoxfGP53p Hsv2i_znVkK6VQG9l5Wfcfbj4Rq7sdQVawdsqwC8a43DVATDPKLtTt0uc9ukrKSpljBrhafGref. eh24C4clF2dDJzXQw2cJ40ECOS5mTq_la8kLMV2ub4EYaat4SMU1ZQveVnBbR40oux4H_8tHn_h1 yk46rf0slnBaJVbHrs5KkjjOpFUeWOkGY03KKSA1ITn_8q4wf9ucyG5UhI.0JqPaC27lYe.Co26G dMIgqermEFASbn8_LQY5L18Qy3Asd_YRglgf7e5Q4n3vbVhBfg_dT.aaxbMplsy7pwv_txPy1mWT 4Klllub3NaM8TflBDeb_FDH7A8aHuvIJrLQ4s7nVANN11FsZkEu8MV4GYoO4JxACJzxax1Pa0YoD eZMq9YiDQNLmzNeCQexVH8uDfMixcxBOubLv_czXGFx2OBaYb6bV5zmaQfZeh5qg0dHDKsKMGMFW 8oKplj758UdgFNQL.mT7XO6AJJ2vrxn9JY7X6iHT8lgKzcSd4fHx3UdPUVjqO_zcp6anP_Lbm9Kn DteExVVAlw.GvVNtZVLqXo6iMhDO50fKNAIUzEi4Bi.C_x7zeYEZgwh_DofbxyomWLO3ZbvhAzvf .WpNLoAvRZnDBlBa_WOqzioSE5qa66i7vnVuvuqNL2oIa.jt.L.CPwiof5HeIbZ1CCWoemuirLM7 ede2oVIBSx5TyPi2RxXCfX5Yy2ncWKjScNy3xzDfTxeryQxVHVDtPyfUfPuvmv.RCg.olDFZpQHI bum.0HnsaykFNWJVCAsQio_Ca7q7pQ6eDhCsj6xIvH.5kSPcmMP_j.gYodospQnGtpm1d.no7xdt oStLSorYRACewr8tNROXBEedGpk7NV.4WoW5RVYNnKS4W3C_KQtqntdyl_.lBdvZyuuSN8YEVK2z FHLHS1ZXKyw_w5bbGMkUOK4DEuLwdjKFDYcuqmJuMMsLUHUk89pK882JNUfdrXD_FnMah Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Jul 2020 04:02:08 +0000 Received: by smtp419.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b24ec34e48c2c4158676bc799ed0ec4; Thu, 23 Jul 2020 04:02:03 +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: Wed, 22 Jul 2020 21:02:02 -0700 Cc: "pkubaj@freebsd.org" , FreeBSD ports Content-Transfer-Encoding: quoted-printable Message-Id: <6C21ED1D-BDE8-4E28-A56E-76A670B66ED6@yahoo.com> References: To: Jan Beich X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4BBzDf3XYLz41ky X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.05 / 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.55)[-0.545]; 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.01)[-1.008]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148: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 04:02:11 -0000 On 2020-Jul-22, at 17:16, Mark Millard wrote: > 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 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: BUILD_DEPENDS+=3D llvm${LLVM_DEFAULT}>0:devel/llvm${LLVM_DEFAULT} \ . . . MOZ_EXPORT+=3D ${CONFIGURE_ENV} \ LLVM_CONFIG=3Dllvm-config${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 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). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)