v1.3.0 build failures on mipsel & armel

[mr-c]

Dear cereal people; thank you for the recent v1.3.0 release!

While preparing the updated Debian package we had build failures on two architectures: mipsel & armel while linking the test_atomic executable:

https://buildd.debian.org/status/fetch.php?pkg=libcereal&arch=armel&ver=1.3.0-1&stamp=1572196759&raw=0

[ 50%] Linking CXX executable test_atomic
cd /<<PKGBUILDDIR>>/obj-arm-linux-gnueabi/unittests && /usr/bin/cmake -E cmake_link_script CMakeFiles/test_atomic.dir/link.txt --verbose=1
/usr/bin/c++  -Werror -Wall -g -Wextra -Wshadow -pedantic -Wold-style-cast -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wl,-z,relro CMakeFiles/test_atomic.dir/atomic.cpp.o  -o test_atomic 
/usr/bin/ld: CMakeFiles/test_atomic.dir/atomic.cpp.o: in function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/usr/include/c++/9/bits/atomic_base.h:419: undefined reference to `__atomic_load_8'
# much more follows

https://buildd.debian.org/status/fetch.php?pkg=libcereal&arch=mipsel&ver=1.3.0-1&stamp=1572197674&raw=0

[ 50%] Linking CXX executable test_atomic
cd /<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/unittests && /usr/bin/cmake -E cmake_link_script CMakeFiles/test_atomic.dir/link.txt --verbose=1
/usr/bin/c++  -Werror -Wall -g -Wextra -Wshadow -pedantic -Wold-style-cast -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -Wl,-z,relro CMakeFiles/test_atomic.dir/atomic.cpp.o  -o test_atomic 
/usr/bin/ld: CMakeFiles/test_atomic.dir/atomic.cpp.o: in function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/usr/include/c++/9/bits/atomic_base.h:419: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:419: undefined reference to `__atomic_load_8'
/usr/bin/ld: CMakeFiles/test_atomic.dir/atomic.cpp.o: in function `std::atomic<double>::load(std::memory_order) const':
# much more follows

Previous releases of cereal did not have these problems on these architectures.

Any assistance in fixing this is appreciated, cheers!

[AzothAmmo]

From some searching around it might be the case that for these architectures we need to link against -latomic.

[mr-c]

@AzothAmmo That was the guess of @h-2 as well. Alas, testing under qemu I still get the error even with -latomic:

[ 54%] Linking CXX executable test_atomic
cd /build/libcereal-1.3.0/obj-mipsel-linux-gnu/unittests && /usr/bin/cmake -E cmake_link_script CMakeFiles/test_atomic.dir/link.txt --verbose=1
/usr/lib/ccache/c++  -Werror -Wall -g -Wextra -Wshadow -pedantic -Wold-style-cast -g -O2 -fdebug-prefix-map=/build/libcereal-1.3.0=. -fstack-protector-strong -Wformat -Werror=format-security -latomic -Wdate-time -D_FORTIFY_SOURCE=2  -Wl,-z,relro CMakeFiles/test_atomic.dir/atomic.cpp.o  -o test_atomic 
/usr/bin/ld: CMakeFiles/test_atomic.dir/atomic.cpp.o: in function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/usr/include/c++/9/bits/atomic_base.h:419: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:419: undefined reference to `__atomic_load_8'

[AzothAmmo]

Hm. Looking at a similar issue with another project (spdlog), latomic seemed to do the trick for them: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909938.

That flag is getting passed to the linker too, right?

Also check out this link and CTRL F for atomic - some useful discussion about the flags:

2017-07-02 07:59:10	gitter	(fornwall) @vishalbiswas I get an undefined reference to `__atomic_load_8` when building mariadb for i686. I thought adding `LDFLAGS+=" -latomic"` would fix that, but it does not

2017-07-02 08:00:11	gitter	(fornwall) but it does seem to work fine on 32-bit arm, which is nice!

2017-07-02 08:27:46	live_the_dream	yeah least used arch is i686

2017-07-02 15:04:58	fornwall	live_the_dream: right, deprecating and moving towards dropping i686 probably makes sense

2017-07-02 15:41:48	gitter	(fornwall) @vishalbiswas ok, `CFLAGS+=" -latomic"` actually fixed i686

2017-07-02 15:41:56	gitter	(fornwall) instead of LDFLAGS

Another maybe useful link

If we can figure out the right flags to make this work, it'll just be a case of putting the logic into CMAKE to populate them when necessary.

[mr-c]

Okay, the reason the adding -latomic to LDFLAGS wasn't working is due to where in the command line cmake adds $LDFLAGS; for cereal the -latomic needs to come last.

Here is how we fixed in for the Debian package, which successfully built and passed the tests on all of Debian's platforms:

https://salsa.debian.org/med-team/libcereal/commit/e551f7c776b36e3d6f9a98980fb8e2cabeedf7ad https://buildd.debian.org/status/logs.php?pkg=libcereal&ver=1.3.0-2&suite=sid

There are some interesting looking cmake files out there that can detect when -latomic is needed and the set -DCMAKE_CXX_STANDARD_LIBRARIES=-latomic accordingly, so that is probably the better long term solution for cereal than hardcoding an architecture list

[AzothAmmo]

See https://github.com/llvm-mirror/llvm/blob/master/cmake/modules/CheckAtomic.cmake for a potential CMAKE solution