Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jul 2020 09:25:19 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Jan Beich <jbeich@FreeBSD.org>
Cc:        "pkubaj@freebsd.org" <pkubaj@FreeBSD.org>, FreeBSD ports <freebsd-ports@freebsd.org>
Subject:   Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)
Message-ID:  <E0E583C8-D000-40DD-83AE-6409858E29D8@yahoo.com>
In-Reply-To: <6C21ED1D-BDE8-4E28-A56E-76A670B66ED6@yahoo.com>
References:  <E062392D-1207-48D4-B503-5EC2227D2D20.ref@yahoo.com> <E062392D-1207-48D4-B503-5EC2227D2D20@yahoo.com> <v9if-s1ax-wny@FreeBSD.org> <C3EF3AFE-A9A0-4924-A83C-7D6812BCB3EE@yahoo.com> <6C21ED1D-BDE8-4E28-A56E-76A670B66ED6@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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:
>=20
>> On 2020-Jul-22, at 14:11, Jan Beich <jbeich at FreeBSD.org> wrote:
>>=20
>>> Mark Millard via freebsd-ppc <freebsd-ppc at freebsd.org> 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

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
=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 <bsd.port.pre.mk>
=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


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:

/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} =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

may be reasonable.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0E583C8-D000-40DD-83AE-6409858E29D8>