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

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

[Zoltan Gyarmati]

On ARC libusb needs BR2_ARC_ATOMIC_EXT to be enabled. I'm not sure this
is the canonical way to express this, please let me know if there is a
more straightforward way.

Zoltan Gyarmati (1):
  package/libusb: set dependency on BR2_ARC_ATOMIC_EXT

 package/libusb/Config.in | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.34.1

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

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

[Zoltan Gyarmati]

Fixes:
  - http://autobuild.buildroot.net/results/459401bab825acf764cdbb156d1ce012183e9b94
Signed-off-by: Zoltan Gyarmati <zgyarmati@zgyarmati.de>
---
 package/libusb/Config.in | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

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)
 	help
 	  Userspace library for accessing USB devices
 
@@ -14,6 +15,7 @@ config BR2_PACKAGE_LIBUSB_EXAMPLES
 
 endif
 
-comment "libusb needs a toolchain w/ threads, gcc >= 4.9"
+comment "libusb needs a toolchain w/ threads, gcc >= 4.9, on ARC the atomic extension"
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || \
-		!BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
+		!BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 || \
+		(BR2_arc && !BR2_ARC_ATOMIC_EXT)
-- 
2.34.1

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

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

[Thomas Petazzoni via buildroot]

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

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

[Zoltan Gyarmati]

[-- 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