On 2020-Jul-22, at 14:11, Jan Beich <jbeich at FreeBSD.org> wrote: > Mark Millard via freebsd-ppc <freebsd-ppc at freebsd.org> writes: > >> ../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. > > 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 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: . . . 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=/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=/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=/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 (g...@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=/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 (g...@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=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c ../src/util/u_atomic.c . . . 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. At this point I'm unclear if: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464 is relevant. The system-clang and devel/llvm80 mix just does not seem the right kind of thing to be doing in the build. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)
Mark Millard via freebsd-ports Wed, 22 Jul 2020 17:17:35 -0700
- 32-bit powerpc graphics/mesa-dri build fail... Mark Millard via freebsd-ports
- Re: 32-bit powerpc graphics/mesa-dri b... Jan Beich
- Re: 32-bit powerpc graphics/mesa-d... Mark Millard via freebsd-ports
- Re: 32-bit powerpc graphics/me... Mark Millard via freebsd-ports
- Re: 32-bit powerpc graphic... Mark Millard via freebsd-ports
- Re: 32-bit powerpc gr... Mark Millard via freebsd-ports