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

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot