| Message ID | 20240814204912.7116-2-zgyarmati@zgyarmati.de |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | package/libusb: set dependency on BR2_ARC_ATOMIC_EXT | expand |
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
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
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)
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(-)