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 (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.
>
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).
===
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"
