32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)
Mark Millard
marklmi at yahoo.com
Thu Jul 23 20:20:50 UTC 2020
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 (git at 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 (git at 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.
>>>
>>
>> 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)
More information about the freebsd-ports
mailing list