Re: [Buildroot] [RFC 1/1] package/libusb: set dependency on BR2_ARC_ATOMIC_EXT

[Zoltan Gyarmati <zgyarmati@zgyarmati.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3303 bytes --]



Dear Thomas&All,

yep, i was afraid that that there is more to this, that's why i sent it 
in as RFC.
Let's see what is Alexey's and Yuriy's opinion on this and i'll 
investigate further as needed.

Thx

On 2024-08-14 23:16, Thomas Petazzoni wrote:

> Hello Zoltan,
> 
> Alexey, Yuriy, there is a potentially ARC-specific issue below.
> 
> On Wed, 14 Aug 2024 22:49:11 +0200
> Zoltan Gyarmati <zgyarmati@zgyarmati.de> wrote:
> 
>> diff --git a/package/libusb/Config.in b/package/libusb/Config.in
>> index 5a04ac128b..637a0c7d4d 100644
>> --- a/package/libusb/Config.in
>> +++ b/package/libusb/Config.in
>> @@ -2,6 +2,7 @@ config BR2_PACKAGE_LIBUSB
>> bool "libusb"
>> depends on BR2_TOOLCHAIN_HAS_THREADS
>> depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 # _Thread_local
>> +    depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT)
> 
> Thanks a lot for looking into this issue!
> 
> However, this is not the right fix. First, because other architecture
> can be affected: sparcv8 most likely would suffer from the same issue.
> 
> Second because the proper solution is to ensure that libusb links
> against libatomic, which contains the implementation of
> __atomic_fetch_add_4 for architectures for which it is not a compiler
> built-in.
> 
> There is already some provision for this in configure.ac:
> 
> dnl Check for new-style atomic builtins. We first check without linking 
> to -latomic.
> AC_MSG_CHECKING(whether __atomic_load_n is supported)
> AC_LINK_IFELSE([AC_LANG_SOURCE([[
> #include <stdint.h>
> int main() {
> struct {
> uint64_t *v;
> } x;
> return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
> (int)__atomic_add_fetch(x.v, (uint64_t)1, __ATOMIC_ACQ_REL);
> }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=yes, 
> GCC_ATOMIC_BUILTINS_SUPPORTED=no)
> AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_SUPPORTED)
> if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != xyes; then
> AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
> fi
> 
> But it doesn't seem to work in this case:
> 
> checking whether __atomic_load_n is supported... no
> checking for library containing __atomic_fetch_add_4... no
> 
> The configure test fails like this:
> 
> configure:17559: 
> /home/autobuild/autobuild/instance-13/output-1/per-package/libusb/host/bin/arc-buildroot-linux-uclibc-gcc 
> -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
> -D_FILE_OFFSET_BITS=64  -O2 -g0  -D_LARGEFILE_SOURCE 
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  conftest.c -latomic   >&5
> conftest.c:33:6: warning: conflicting types for built-in function 
> '__atomic_fetch_add_4'; expected 'unsigned int(volatile void *, 
> unsigned int,  int)' [-Wbuiltin-declaration-mismatch]
> 33 | char __atomic_fetch_add_4 ();
> |      ^~~~~~~~~~~~~~~~~~~~
> /home/autobuild/autobuild/instance-13/output-1/per-package/libusb/host/bin/../lib/gcc/arc-buildroot-linux-uclibc/14.2.0/../../../../arc-buildroot-linux-uclibc/bin/ld: 
> /home/autobuild/autobuild/instance-13/output-1/per-package/libusb/host/bin/../lib/gcc/arc-buildroot-linux-uclibc/14.2.0/../../../../arc-buildroot-linux-uclibc/lib/libatomic.so: 
> undefined reference to `__atomic_test_and_set'
> collect2: error: ld returned 1 exit status
> 
> This is rather odd. Is there a bug in ARC's libatomic implementation?
> Alexey, Yuriy, what do you think?
> 
> Thanks a lot,
> 
> Thomas

-- 
https://zgyarmati.de

[-- Attachment #1.2: Type: text/html, Size: 5584 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot