On Tue, Nov 23, 2021 at 10:14 PM Thomas Goirand <zigo@xxxxxxxxxx> wrote: > > Hi, > > I'm maintaining Ceph in Debian. That's probably the only distro where we > have a mips64el port. And it fails there: > > https://buildd.debian.org/status/package.php?p=ceph&suite=experimental > > (click on the "Build-Attempted" to see the build log in front of mips64el) > > This CPU doesn't support atomic operations, so it must use the emulation > provided by the lib atomic. So "-latomic" should be added to the command > line. > > I've first tried to add in debian/rules: > > DEB_LDFLAGS_MAINT_APPEND=-latomic > > but this puts -latomic at the beginning of the command line, before the > Ceph internal .so, which fails. > > So I tried another approach which was to patch the CMakeLists.txt: > > --- ceph-16.2.6+ds.orig/src/tools/rbd_mirror/CMakeLists.txt > +++ ceph-16.2.6+ds/src/tools/rbd_mirror/CMakeLists.txt > @@ -71,6 +71,7 @@ add_library(rbd_mirror_internal STATIC > add_executable(rbd-mirror > main.cc) > target_link_libraries(rbd-mirror > + atomic > rbd_mirror_internal > rbd_mirror_types > rbd_api > --- a/src/mgr/CMakeLists.txt 2021-11-03 11:57:18.576976453 +0100 > +++ b/src/mgr/CMakeLists.txt 2021-11-21 22:46:46.353082042 +0100 > @@ -37,7 +37,8 @@ > osdc client heap_profiler > global-static ceph-common > Boost::python${MGR_PYTHON_VERSION_MAJOR}${MGR_PYTHON_VERSION_MINOR} > - Python3::Python ${CMAKE_DL_LIBS} ${GSSAPI_LIBRARIES}) > + Python3::Python ${CMAKE_DL_LIBS} ${GSSAPI_LIBRARIES} > + atomic) > set_target_properties(ceph-mgr PROPERTIES > POSITION_INDEPENDENT_CODE ${EXE_LINKER_USE_PIE}) > install(TARGETS ceph-mgr DESTINATION bin) > > This worked for the libs, but failed when building rbd_mirror binary. > > So my question is: what's the best way, for a Debian package, to make > Ceph add -latomic *AT THE END* of the command line? hi zigo, cmake/modules/CheckCxxAtomic.cmake is supposed to prepare the link flags for the platform where the glibc or the platform does not offer builtin atomic operations, and the libatomic should be linked. and we check this ability by compiling and linking following C++ program with -std=c++11 ====8<====== #include <atomic> #include <cstdint> #if __s390x__ // Boost needs 16-byte atomics for tagged pointers. // These are implemented via inline instructions on the platform // if 16-byte alignment can be proven, and are delegated to libatomic // library routines otherwise. Whether or not alignment is provably // OK for a std::atomic unfortunately depends on compiler version and // optimization levels, and also on the details of the expression. // We specifically test access via an otherwise unknown pointer here // to ensure we get the most complex case. If this access can be // done without libatomic, then all accesses can be done. bool atomic16(std::atomic<unsigned __int128> *ptr) { return *ptr != 0; } #endif int main() { std::atomic<uint8_t> w1; std::atomic<uint16_t> w2; std::atomic<uint32_t> w4; std::atomic<uint64_t> w8; return w1 + w2 + w4 + w8; } =====>8============= using check_cxx_source_compiles("<the-source-code-here>"). but it seems that the mips64el build host managed to the test: <snip> ... -- Performing Test HAVE_CXX11_ATOMIC -- Performing Test HAVE_CXX11_ATOMIC - Success ... </snip> while failed when linking rbd.cc.o and some other object files: <snip> ... /usr/bin/ld: ../../../lib/librbd.so.1.16.0: undefined reference to `__atomic_store_16' /usr/bin/ld: ../../../lib/librbd.so.1.16.0: undefined reference to `__atomic_load_16' /usr/bin/ld: ../../../lib/librbd.so.1.16.0: undefined reference to `__atomic_compare_exchange_16' ... </snip> in other words, the test cmake script fails to do its job. so i created https://github.com/ceph/ceph/pull/44071 to address this FTBFS on mips64el. > > As for the mipsel arch, the error is: > virtual memory exhausted: Cannot allocate memory > > so I'd need to save some memory at build time, somehow. Tips would be > appreciated. hmm, the memory consumption is always an issue. but the "Status" cell in the "mipsel" row is not a hyperlink in https://buildd.debian.org/status/package.php?p=ceph&suite=experimental, so i cannot check or at least try to figure out who was using the memory at that very moment.. > > For armel, the issue is: > /tmp/cc3CvITT.s:2594: Error: selected processor does not support `yield' > in ARM mode > > Does anyone know how to fix that? it's should be a bug tracked by https://github.com/facebook/folly/issues/1159 . could you try to upgrade rocksdb submodule which includes the fix to address this issue? probably you will have to backport https://github.com/ceph/ceph/pull/42815 to build with a newer rocksdb. > Thanks in advance for anyone who will help, no problem. and thank you! > > Cheers, > > Thomas Goirand (zigo) > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx -- Regards Kefu Chai _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
