* isal needs nasm, which is a new dependency. so let's disable it
at this moment.
* vhost requires DPDK compiled with vhost enabled. but it's disabled
when we compile DPDK.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* update execenv to remove "app", the targets ending with "app" changed
to the ones without "app" now.
* pass CC by make variables not env variables, otherwise the default
`cc` is used
Signed-off-by: Kefu Chai <kchai@redhat.com>
The next patch adds netlink support to rbd-nbd. This patch just adds the
build related changes to bring in the netlink lib and test and build
against it.
Signed-off-by: Mike Christie <mchristi@redhat.com>
as the flags should be a string, not a list
tested using
cmake -DCMAKE_LINKER=gold -DWITH_ASAN=ON -DWITH_ASAN_LEAK=ON \
-DCMAKE_BUILD_TYPE=Debug
on ubuntu xenial
without this change, cmake will fail with following warning:
CMake Error at src/CMakeLists.txt:112 (message):
The compiler /usr/bin/c++ has no C++17 support.
-- Configuring incomplete, errors occurred!
Signed-off-by: Kefu Chai <kchai@redhat.com>
ninja scan the build dependencies differently than GNU make, so we need
to specify the product of `ExternalProject_Add()`. with this change,
we can build `vstart-base` without building the ExternalProject
separately.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* modules/BuildDPDK.cmake: always use "make"
* modules/BuildSPDK.cmake: always use "make"
DPDK only support "make". if user wants to use other generator than
"make", we will fail to build DPDK support. so we should always use
"make" here. and before using "make", we need to detect it.
* cmake/modules/BuildRocksDB.cmake: use cmake for build
* src/compressor/zstd/CMakeLists.txt: use cmake for build
just use whatever generator use specifies, and use ${CMAKE_COMMAND}
for building the specified target, no need to repeat
${CMAKE_GENERATOR} for building the target.
Signed-off-by: Kefu Chai <kchai@redhat.com>
There is a lot of good stuff going on here, but nobody is investing in xio
and it is not expected to be the path forward for RDMA. If that ever
changes, we can resurrect the code. Until then, let's clean up the tree
and reduce friction for changes going forward.
Signed-off-by: Sage Weil <sage@redhat.com>
Commit 3bde34af8a removed cython 0.29's subinterpreter check when
building the various python modules during `make`, but unforunately
they're *rebuilt* during `make install`, with the rebuild overwriting
the original build. The original fix was of course missing from the
install stage...
Fixes: https://tracker.ceph.com/issues/38788
Signed-off-by: Tim Serong <tserong@suse.com>
rabbitmq-c is not a header-only library. so we need to ensure that the
library is also around before linking against it. in this change:
* move the detection down to where librabbitmq is used
* add FindRabbitMQ.cmake for find_package(RabbitMQ)
* s/rabbitmq/RabbitMQ::RabbitMQ/ as the latter is an alias library
target, which has more information attached to it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
cython 0.29 introduced a check which prevents multiple python
subinterpreters from loading the same module:
https://github.com/cython/cython/commit/7e27c7c
Unfortunately, this completely breaks ceph-mgr. Until we can
figure out a better long term solution, this commit removes
cython's subinterpreter check, via some careful abuse of the
C preprocessor.
This works because when cython is invoked, it first generates
some C code, then compiles it. We know it's going to generate
C code including:
int __Pyx_check_single_interpreter(void) { ... }
and:
if (__Pyx_check_single_interpreter())
return NULL;
So, we can do the following:
#define void0 dead_function(void)
#define __Pyx_check_single_interpreter(ARG)=ARG ## 0
This replaces the call to __Pyx_check_single_interpreter()
with a literal 0, removing the subinterpreter check.
The void0 dead_function(void) thing is necessary because
the __Pyx_check_single_interpreter() macro also clobbers
that function definition, so we need to make sure it's
replaced with something that works as a function definition.
Fixes: https://tracker.ceph.com/issues/37472
Signed-off-by: Tim Serong <tserong@suse.com>
--single-version-externally-managed is used for packaging python eggs
to deb. so the metadata can be stored in the egg, and can be accessed
by user if necessary, see [1]. but this does not apply to users who
just want to "make install" without packaging Ceph.
the problem is, if we pass --single-version-externally-managed to
setup.py, we need to pass --record or --root also. otherwise setuptools
complains:
error: You must specify --record or --root when building system packages
so in this change, we choose not to pass
"--single-version-externally-managed", unless $DESTDIR is set.
both "ceph.spec.in" and "debian/rules" set $DESTDIR when running "make
install". so we can always check $DESTDIR to tell if current "make
install" is launched by the packaging script or not. this might not be
accurate, but good enough. assuming enduser does not use DESTDIR when
running plain "make install".
--
[1] https://wiki.debian.org/Python/FAQ#How_should_we_package_Python_eggs.3F
Signed-off-by: Kefu Chai <kchai@redhat.com>
It is rather had to overide a once set timeout during CTesting.
This is the best next compromise. Disadvantage is that a rebuild
is required.
But it helps in my Jenkins testing timely catching run-away programs.
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
in python's distutils.ccompiler, linker_exe is composed using CC instead
of LDFLAGS. the latter only effects how it builds (shared) library.
and put CMAKE_C_FLAGS into the cflags for the compiler for building
python C extensions, it's more consistent this way. more importantly,
if we build with ASan enabled, the canary program, a.k.a. rados_dummy.c,
won't link without proper CFLAGS.
without this change, rados.so fails to build with errors like:
/usr/bin/ld: /var/ssd/ceph/build/lib/librados.so: undefined reference to
`__asan_stack_free_10'
/usr/bin/ld: /var/ssd/ceph/build/lib/librados.so: undefined reference to
`__asan_report_exp_store8'
...
...
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
Link Error: RADOS library not found
make[3]: ***
[src/pybind/rados/CMakeFiles/cython_rados.dir/build.make:57:
src/pybind/rados/CMakeFiles/cython_rados] Error 1
Signed-off-by: Kefu Chai <kchai@redhat.com>
When building with ccache, distcc, and other compiler wrappers (such
as STLFilt):
CC='ccache gcc' CXX='ccache g++' cmake /path/to/ceph
make
python modules fail to compile since distutils try to execute the
wrapper itself without specifying the actual compiler.
Although cmake has a special magic switch for compiling with ccache
(cmake -DWITH_CCACHE=ON) other tools (distcc) are not supported, and
specifying the compiler as
CC=/whatever/compiler/is
used to work for decades, and it's a good idea to keep it working
Signed-off-by: Alexey Sheplyakov <asheplyakov@mirantis.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
Make sure the mbuf and ethdev libraries are created as they export
required symbols.
Fixes: http://tracker.ceph.com/issues/36341
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
we are using GCC7 and up for C++17 support since mimic, and per
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/AArch64-Options.html ,
GCC 4.9 and up should be able to support crc and crypto features if
these archs are enabled at GCC's configure-time. so we should always use
the -march for detecting the compiler's support instead of using the
inline assembly now.
GCC 4.8 is an ancient compiler, and per
https://gcc.gnu.org/gcc-4.8/changes.html, it was the the first GCC
release which offers AArch64 support. so we don't need to cater for
this GCC version. and we can trust GCC-7 and up.
Fixes: http://tracker.ceph.com/issues/17516
Signed-off-by: Kefu Chai <kchai@redhat.com>
the FindBoost.cmake shipped by cmake 3.5.1 is not new enough to identify
the dependencies of boost 1.63 and up. so we need to copy the
FindBoost.cmake from cmake upstream. it supports up to boost 1.68.
Signed-off-by: Kefu Chai <kchai@redhat.com>
we build dpdk as static library, linking against them without specifying
--whole-archive will get the constructor symbols droppped by the linker
as they are not referenced directly by the excecutable. so we need to do
so to make sure we call all the constructors.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* add Findcryptopp.cmake back
cryptopp support was dropped in #20015, but it's required by
src/msg/async/dpdk/TCP.h, which `#include <cryptopp/md5.h>`
so, to fix the FTBFS of WITH_DPDK=ON, we need to bring
Findcryptopp.cmake back. it was also removed in #20015.
* pass "-march=core2" when building sources which include dpdk headers.
i was wrong that the headers shipped by distro are generic.
the headers use the sse instructions for speedup memcpy, see
/usr/include/x86_64-linux-gnu/dpdk/rte_memcpy.h .
* also, we need to include the arch specific include directory
for building with dpdk.
Signed-off-by: Kefu Chai <kchai@redhat.com>
