gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] [RFC] util: fix build with external libatomic


From: Daniel Golle
Subject: Re: [GNUnet-developers] [RFC] util: fix build with external libatomic
Date: Thu, 21 Feb 2019 21:52:45 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

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) \
> > 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]