On 2020-Jul-23, at 09:25, Mark Millard <marklmi at yahoo.com> wrote: > > On 2020-Jul-22, at 21:02, Mark Millard <marklmi at yahoo.com> wrote: > >> On 2020-Jul-22, at 17:16, Mark Millard <marklmi at yahoo.com> wrote: >> >>> 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 ([email protected]: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 ([email protected]: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. >>> >> >> 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+= llvm${LLVM_DEFAULT}>0:devel/llvm${LLVM_DEFAULT} \ >> . . . >> >> MOZ_EXPORT+= ${CONFIGURE_ENV} \ >> LLVM_CONFIG=llvm-config${LLVM_DEFAULT} \ >> . . . >> >> . if ${CC} == cc && ${CXX} == c++ && exists(/usr/lib/libc++.so) >> BUILD_DEPENDS+= >> ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} >> CPP= ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} >> CC= ${LOCALBASE}/bin/clang${LLVM_DEFAULT} >> CXX= ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} >> USES:= ${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). >> > > 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: > > # svnlite diff /usr/ports/graphics/mesa-dri/ | more > Index: /usr/ports/graphics/mesa-dri/Makefile.common > =================================================================== > --- /usr/ports/graphics/mesa-dri/Makefile.common (revision 542111) > +++ /usr/ports/graphics/mesa-dri/Makefile.common (working copy) > @@ -85,8 +85,8 @@ > > .include <bsd.port.pre.mk> > > -.if ${ARCH} == powerpc64 > -LLVM_DEFAULT= 90 > +.if ${ARCH} == powerpc64 || ${ARCH} == powerpc > +LLVM_DEFAULT= 10 > .elif ${LLVM_DEFAULT:C/[1-5]./&0/:S,-devel,990,} >= 90 > LLVM_DEFAULT= 80 > .endif > @@ -97,6 +97,13 @@ > MESON_ARGS+= -Dllvm=false > .else > BUILD_DEPENDS+= llvm${LLVM_DEFAULT}>=3.9.0_4:devel/llvm${LLVM_DEFAULT} > +. if ${CC} == cc && ${CXX} == c++ && exists(/usr/lib/libc++.so) > +BUILD_DEPENDS+= > ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} > +CPP= ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} > +CC= ${LOCALBASE}/bin/clang${LLVM_DEFAULT} > +CXX= ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} > +USES:= ${USES:Ncompiler\:*} # XXX avoid warnings > +. endif > .if ${COMPONENT} != libs > RUN_DEPENDS+= llvm${LLVM_DEFAULT}>=3.9.0_4:devel/llvm${LLVM_DEFAULT} > .endif > > > 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=c++11 . So clang++10 rejects the likes of: > > /usr/local/llvm10/include/llvm/ADT/STLExtras.h:559:49: error: no template > named 'index_sequence' in namespace 'std' > template <size_t... Ns> value_type deref(std::index_sequence<Ns...>) const { > > > But /usr/local/bin/clang++10 and such was used, matching the LLVM_DEFAULT > I'd set. So the: > > +. if ${CC} == cc && ${CXX} == c++ && exists(/usr/lib/libc++.so) > +BUILD_DEPENDS+= > ${LOCALBASE}/bin/clang${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT} > +CPP= ${LOCALBASE}/bin/clang-cpp${LLVM_DEFAULT} > +CC= ${LOCALBASE}/bin/clang${LLVM_DEFAULT} > +CXX= ${LOCALBASE}/bin/clang++${LLVM_DEFAULT} > +USES:= ${USES:Ncompiler\:*} # XXX avoid warnings > +. endif > > may be reasonable. > 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) = (_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= in the Makefile? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
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 Thu, 23 Jul 2020 13:21:04 -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
