Hallo,
* John Paul Adrian Glaubitz [Sun, May 07 2017, 11:35:48AM]:
> Source: apt-cacher-ng
> Version: 3-5
> Severity: normal
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: m68k
> 
> Hello!
> 
> Currently, apt-cacher-ng fails to build from source on m68k,
> powerpc, powerpcspe and sh4 because it's missing '-latomic'
> from the linker options. This happens because the current
> approach for passing -latomic is done based on a white-list
> basis which is not the optimal approach:
> 
> # libatomic provides 8-bytes atomic operation for 32-bit MIPS
> ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
>  EXTRA_LIBS="-DEXTRA_LIBS_ACNG=-latomic"
> endif
> 
> It's rather better to just use "--as-needed" and let the linker
> decided whether -latomic is needed. This way, it's not longer
> necessary to maintain a whitelist and adjust it for future
> architectures:
> 
> EXTRA_LIBS="-DEXTRA_LIBS_ACNG=-Wl,--as-needed -latomic"
> 
> With the attached patch, apt-cacher-ng builds fine on all
> affected architectures, including mips and mipsel.

Although you patch works, the analysis is not fully correct. Yes, you
found that part debian/rules but the only reason it's there is because
it was forgotten. It was useful in early versions, in the meantime the
upstream build system got the proper check for libatomic (see
CMakeLists.txt), and -Wl,as-needed is also used where possible.
I just forgot to remove the Debian workaround(s).

And the new scheme has been working for a while and broke again now, and
because of the remains of the mentioned workaround the issue was not
spotted immediately.

The check code is:

FIND_LIBRARY(HAVE_ATOMICLIB atomic) # needed for global atomic vars on some 
32bit architectures
if(HAVE_ATOMICLIB)
        MESSAGE("-- Found libatomic development files, will link libatomic")
        LIST(APPEND BaseNetworkLibs atomic)
endif()

Apparently that check is no longer succeeding. I need to check on
porter machines and fix the detection. Looking at CMakeLists.txt alone
does not help, it should basically work.

Regards,
Eduard.

Reply via email to