On Thu, Feb 21, 2019 at 09:07:07PM +0100, Christian Grothoff wrote: > Hi Daniel, > > The patch looks fine as-is. As for the warning, I don't think it can be > fixed as it seems that libtool looks at the transitive dependency chain.
Hm, I thought this could be avoided in configure.ac somehow by all the SAFE_LIBS=$LIBS ... LIBS=$SAFE_LIBS *Not* doing that (ie. having -latomic in LIBS) also prevents the warning, but still results in unrelated libraries being linked against libatomic without using any of its symbols. > The best way to fix the warning would seem to be to fix how libatomic is > build on LEDE (as in: not move it, or maybe build in chroot). I'm still wondering where would be the right place to fix this. OpenWrt's libtool hack? Or gcc being smart enough to auto-link against libatomic if needed? (jow, nbd: any ideas?) > > Please push the change soon, so we have it for 0.11.0. I will, because without it builds on MIPS and PCC are failing now... Cheers Daniel > > Thanks! > > Christian > > On 2/21/19 8:41 PM, Daniel Golle wrote: > > Recent versions of gcc on some architectures (MIPS, PPC, ...) moved > > atomic functions into a separate library. As we are using atomic > > load/store in util/time.c we may need to link libgnunetutil against > > libatomic for __atomic_load_8 and __atomic_store_8 to be defined. > > > > Fixes build problem on MIPS: > > ld: ./.libs/libgnunetutil.so: undefined reference to `__atomic_store_8' > > ld: ./.libs/libgnunetutil.so: undefined reference to `__atomic_load_8' > > collect2: error: ld returned 1 exit status > > > > This patch, however, causes an endless number of > > libtool: relink: warning: > > `/usr/src/lede/staging_dir/toolchain-mipsel_24kc_gcc-7.4.0_musl/lib/libatomic.la' > > seems to be moved > > lines printed during build and almost every shared library is linked > > against libatomic in the end (though it would really only be needed > > for libgnunetutil). Apparently libtool's dependency_libs is the problem > > or at least that's where the absolute path of libatomic.la in LIBS > > comes from. I was trying to resolve this autotools mess for 2 hours now > > and didn't manage to *not* have libtool care about libatomic. > > > > Ideas? > > --- > > configure.ac | 7 ++++++- > > src/util/Makefile.am | 7 +++++++ > > 2 files changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/configure.ac b/configure.ac > > index 8b93d8d6c..00437f2ef 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -676,6 +677,8 @@ else > > AC_DEFINE([HAVE_LIBCURL],[1],[Have CURL]) > > fi > > > > +AC_SEARCH_LIBS(__atomic_load_8, atomic, [have_libatomic=1 > > AC_DEFINE(HAVE_LIBATOMIC,1,[external libatomic])]) > > +AM_CONDITIONAL(HAVE_LIBATOMIC, [test "$have_libatomic" = 1]) > > > > # restore LIBS & CPPFLAGS > > LIBS=$SAVE_LIBS > > diff --git a/src/util/Makefile.am b/src/util/Makefile.am > > index 0ba06f4bb..5fa6e907e 100644 > > --- a/src/util/Makefile.am > > +++ b/src/util/Makefile.am > > @@ -123,6 +123,12 @@ libgnunetutil_la_SOURCES = \ > > speedup.c speedup.h \ > > proc_compat.c > > > > +if HAVE_LIBATOMIC > > + LIBATOMIC= -latomic > > +else > > + LIBATOMIC= > > +endif > > + > > if HAVE_LIBIDN > > LIBIDN= -lidn > > else > > @@ -137,6 +143,7 @@ endif > > > > libgnunetutil_la_LIBADD = \ > > $(GCLIBADD) $(WINLIB) \ > > + $(LIBATOMIC) \ > > $(LIBGCRYPT_LIBS) \ > > $(LTLIBICONV) \ > > $(LTLIBINTL) \ > > > _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
