Since libfuse 3.2 to 3.8 the minor version for FUSE library has
stopped updating together with the releases. So we cannot check
version by using the FUSE_VERSION macro in the fuse_common.h header
file directly.
This will check the major/minor version from the fuse{3}.pc pkconfig
file.
Fixes: https://tracker.ceph.com/issues/45396
Signed-off-by: Xiubo Li <xiubli@redhat.com>
1. WITH_LIBURING is used to set HAVE_LIBURING to decide
use liburing in KernelDevice or not.
2. WITH_SYSTEM_LIBURING is to choose use system installed
liburing or build the liburing from source code.
Signed-off-by: Changcheng Liu <changcheng.liu@aliyun.com>
in 0437adc33a, we stop right before
reaching $top_srcdir, but we should stop at its parent directory.
in this change, instead of trying to be smart and to walk all the way
up to the root directory or $top_srcdir, we just check $top_srcdir/.git
directly, as we just know it's there or it does not exist at all.
Signed-off-by: Kefu Chai <kchai@redhat.com>
make always assume that `cc` is available. but we cannot ensure this,
and furthermore, we need to use the compiler specified by user. so
specify `CC` variable when compiling pmem. and reindent the code to fix
the formatting.
Signed-off-by: Kefu Chai <kchai@redhat.com>
we cannot assume that we are using `make` as the cmake generatator,
for instance, if ninja is used, `$(MAKE)` won't be substituted by ninja.
so we need to check if Make is used as generator, if that's the case, we
can just use `$(MAKE)` so we can benefit from the job control of `make`,
otherwise, `make` is used, because currently, PMDK uses Makefile to
build.
Signed-off-by: Kefu Chai <kchai@redhat.com>
it's a shorthand for finding "make" or "gmake" (for FreeBSD), and set
the path to the executable and the command to use in the generated
"Makefile" or whatever build script generated by cmake.
Signed-off-by: Kefu Chai <kchai@redhat.com>
To build Boost.Context (and other libraries) with support to allow
them to be valground usefully, and to include the define to link
against them.
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
In order to be able to cross compile rocksdb using mingw, we'll
have to do the following:
* pass on specified toolchain files
* pass the CMAKE_PREFIX_PATH. We'll have to replace the ";" separator
with something else (we went with "!"), otherwise CMake won't be
able to properly handle the command arguments
* pass on the received LZ4 lib location since it cannot be properly
detected when cross compiling.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
We'll update the cmake files in order to be able to build ceph
components for Windows targets.
Cross compiling using MINGW is the easiest approach for now.
Subsequently, we'll add support for Clang and MSVC.
This patch provides the following changes:
* include winsock2.h, which provides ntohl on Windows
* avoid unsupported compiler flags when using msvc
* add a custom toolchain file for mingw
* update install command for ceph-common in order to work with mingw
* avoid running test sample when cross compiling
* link against the ws_32 lib
* set argeted Windows version
* skip yasm checks when targeting Windows
* allow multiple redefinitions when using mingw, picking the first one.
this is a workaround for a mingw TLS bug:
https://sourceforge.net/p/mingw-w64/bugs/816/
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Commit d1b9d14324 added a check for
16-byte atomics without library support on IBM Z. Unfortunately
it turns out this test only works correctly when the test case
is built without optimization. (This is normally true, but it
may not be the case when passing explicit CXXFLAGS to cmake.)
The underlying reason is that GCC may choose to use either an
inline implementation of the 16-byte atomics or library calls,
depending on whether or not it is able to prove the atomic
variable is properly aligned. At -O0 it is never able to prove
that, but at higher optimization levels it depends on the complexity
of the expression (in particular, whether GCC can track down the
definition of the underlying object).
As the test case uses a very simple expression, it may happen that
this test can be built without requiring library support, but some
of the "real" uses of atomics in Ceph code cannot. This defeats
the whole purpose of the test at configure time.
Fixed by making the access pattern in the test more complex, so
that the test fails even at high optimization levels.
Fixes: https://tracker.ceph.com/issues/43747
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
BuildBoost.cmake (used when we're building the submodule) doesn't
provide parity with FindBoost.cmake (used with system Boost).
Specifically, it doesn't set the _FOUND variables for the various
components, making it hard to depend on finding those features.
Set Boost_<component>_FOUND for all the components we're building in
BuildBoost.cmake to make using these variables possible.
Signed-off-by: Daniel Gryniewicz <dang@redhat.com>
* drop WITH_PYTHON2 option
* print warning message if WITH_PYTHON3 is disabled
* drop MGR_PYTHON_VERSION option, as we don't support use different
python version for python binding and ceph-mgr embedded python
interpreter anymore. as before switching to python3-only build,
we can build python3 and python2 python bindings, and ceph-mgr
can use either of them. but after switching to python3-only
build, ceph-mgr has to use whatever python version used to
build python binding.
* move WITH_PYTHON3 option to $top_srcdir/CMakeLists.txt, as ceph-mgr
and python binding will share this option.
* hardware ${PYTHON_VERSION} to 3
* hardware ${Python${PYTHON_VERSION}_VERSION_MAJOR} to 3
* only build boost library with python3
* s/Python_EXECUTABLE/Python3_EXECUTABLE/
* update the build scripts and packagings accordingly
* rename all cython${PYTHON_VERSION}_* targets to cython_*
* update distutils_install_module() so it does not take python_version
parameter anymore.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so we can use exported targets like "Python3::Python", which is defined
only if CMAKE_ROLE is "PROJECT". but this global property was introduced
by CMake 3.14, but the minimum required version of CMake is 3.10.2 in
Ceph project at this moment. let's set it if it's not defined.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* remove messages spit when these tools are not found
they are not necessary for building Ceph. and the messages in the cmake
output are distracting.
* fix a typo
Signed-off-by: Kefu Chai <kchai@redhat.com>
CMake CMP0093 was introduced by CMake 3.15, but we only require CMake
v3.10.2. so use the old `Boost_VERSION_MACRO` variable by default,
unless specified otherwise.
Signed-off-by: Kefu Chai <kchai@redhat.com>
CMake CMP0074 was introduced by CMake 3.12, but we only require CMake
v3.10.2. so default to check `Boost_ROOT` unless specified otherwise.
Signed-off-by: Kefu Chai <kchai@redhat.com>
librte_eal.a refers to libpthread.so and libdl.so, and libceph-common.so
refers to librte_eal.a. Many test application link libceph-common.so
without linking pthread, it will cause link error.
Such as unittest_interval_set, target_link_libraries (unittest_interval_set
ceph-common)
Signed-off-by: Chunsong Feng <fengchunsong@huawei.com>
Find and link the numa library for DPDK.
Fixes: https://tracker.ceph.com/issues/42275
Signed-off-by: Hu Ye <yehu5@huawei.com>
Signed-off-by: Chunsong Feng <fengchunsong@huawei.com>
* refs/pull/31781/head:
cmake/modules: look for GNU make first instead of BSD make
cmake: support parallel build for rocksdb
Reviewed-by: Willem Jan Withagen <wjw@digiware.nl>
Reviewed-by: Kefu Chai <kchai@redhat.com>
* BuildDPDK.cmake, BuildSPDK.cmake:
* give priority to build with gmake
* throw error if make not found
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
* cmake/modules/BuildRocksDB.cmake: if "make" detected
use concurrent processing, by passing the jobserver to
sub-make using `$(MAKE)`
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
per clock_gettime(3),
> On POSIX systems on which these functions are available, the symbol
> _POSIX_TIMERS is defined in <unistd.h> to a value greater than 0.
and
> Most systems require the program be linked with the librt library to
> use these functions.
so, we should detect this symbol and link against librt for using these
functions.
in this change, librt is linked for checking the existence of
clock_gettime(), if it exists. RT_LIBRARY is defined.
Signed-off-by: Kefu Chai <kchai@redhat.com>
src/spdk/dpdk and src/seastar/dpdk are both at their private branches
with project-specific modifications, so select proper dpdk source
directory according to flags WITH_SPDK and Seastar_DPDK.
Signed-off-by: Yingxin Cheng <yingxin.cheng@intel.com>
find_package(dpdk...) is used by seastar to find DPDK if Seastar_DPDK is
enabled. but `build_dpdk()` only exposes `dpdk::dpdk`, and it does not
set the variables like `dpdk_INCLUDE_DIRS` and `dpdk_LIBRARIES` when it
gets called. so we need to adapt Finddpdk to query them from `dpdk::dpdk`
target.
Signed-off-by: Kefu Chai <kchai@redhat.com>
dpdk_LIBRARIES should not be a list of dpdk library target, it should be
a list of paths to them. this also align with the definition of
`Finddpdk.cmake` in seastar project. so, if `Seastar_DPDK` is defined,
we should be able to offer the expected `dpdk_LIBRARIES` for seastar, as
our `Finddpdk.cmake` has higher priority than the one in seastar, and is
used when `find_package(dpdk...)` is called.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* extract `do_export_dpdk()` into a separated function
* no need to check for `dpdk-ext` target before calling `build_dpdk()`,
as the name of this target should be hidden from the caller of this
function.
Signed-off-by: Kefu Chai <kchai@redhat.com>
check the linker support of `--version-script` and `--exclude-libs`
flags. and use them only if they are supported.
llvm-ld does not support `--version-script` at this moment. and it's
reported that old versions of llvm-ld do not support `--exclude-libs`
as well.
Signed-off-by: Kefu Chai <kchai@redhat.com>
On IBM Z the Boost tagged pointer implementation cannot use
"pointer compression" as there are no unused bits in an address;
the whole 64-bit address space is available to user space code.
Instead, Boost uses 16-byte atomics. This is always supported
on IBM Z, but depending on the particular compiler (version)
it may require linking against libatomic. The existing checks
in CheckCxxAtomic.cmake do not catch this, however, as they only
test for (up to) 8-byte atomic support.
Fixed by adding a test for 16-byte atomic support on IBM Z.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
These types should no longer be used; use ceph_le16/32/64 instead.
Also removes the cmake check whether those types are provided by
kernel headers (likewise for the __be types, which already were
not used anywhere).
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
On big-endian systems, ntohl is a no-op, so "good" never does
any conversion. Fix this by keeping the test constants in
big-endian (network) order and using ntohl to convert them
to native (host) byte order.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
C and C++ allow us to cast a pointer with an alignment requirement to
one with a different alignment requirement. but if the destination
type's alignment is greater/stricter than the source type, the behavior
is undefined. on amd64, it's allowed. and on aarch64, GCC offers an
option named `-munaligned-access` to enable this behavior. so we cannot
take this as guaranteed.
in denc.h and messenger implementations, we just cast the pointers to
the type we want to access without memcpy(), which is, strictly
speaking, not quite standard compliant.
so, to be on the safe side, we detect the support of unaligned access at
compile time.
please note, this would fail the cross-compile. as the target platform
might not support unaligned access, and the produced executable does not
run on the build platform. so this test is skipped if the building
host's architecture is different than that of target host.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Otherwise it will result in:
[ 59%] preparing venv for mgr-dashboard
New python executable in /home/jenkins/workspace/ceph-master/build/mgr-dashboard-virtualenv/bin/python2.7
Also creating executable in /home/jenkins/workspace/ceph-master/build/mgr-dashboard-virtualenv/bin/python
Installing setuptools, pip, wheel...done.
Running virtualenv with interpreter /usr/local/bin/python2.7
Even though the Cmake options contained:
'-DWITH_PYTHON2=OFF' '-DWITH_PYTHON3=3' '-DMGR_PYTHON_VERSION=3'
Mostly due to the fact that
src/tools/setup-virtualenv.sh
default to:
PYTHON_BINARY="python2.7"
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
Refactor CMake add_tox_test to automatically add py27 and/or py3 to
provided toxenvs.
Refactor tox.ini:
- Remove requirements-{py27,py3}.txt, as python release dependant
packages can be handled with PEP 508 syntax.
- Remove develepment dependencies from requirements.
- Move pycodestyle settings to separate section.
- Add flake8 check and other checkers (rst, naming, etc). Some of them
are commented out for future clean-ups (Ceph trackers have been opened)
- Pycodestyle removed, as flake8 is a wrapper for pycodestyle.
- Add instafail plugin to report failures immediately
- Add timeout plugin to limit max run time (sometimes test_tasks hangs)
- Remove unused dependencies (lru_cache, pluggy)
Test and code linting fixes:
- Unused imports
- Fixes to HACKING.rst
Doc:
- Update HACKING.rst
Add conftest.py to mock imported modules (rados, rbd, cephfs), and mock
also rados Error and OSError Exceptions.
Fixes: https://tracker.ceph.com/issues/40487
Fixes: https://tracker.ceph.com/issues/41152
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
* add two optional keyword parameters to `add_tox_test()`
* use the default `TOX_PATH` parameter instead passing it explicitly,
as it is always `${CMAKE_CURRENT_SOURCE_DIR}`
* drop the code to guess the tox envs in `run_tox.sh`, and always pass
them explicitly in CMake script using the `--tox-envs` argument.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so we can prepare the venv for tox with `make tests`. and it's optional,
as run_tox.sh will check for it and setup a venv if it's not around.
Signed-off-by: Kefu Chai <kchai@redhat.com>
since we dropped the support of xenial, we now have the luxury of using
newer CMake! and by using CMake 3.10.2, we can prevent libfmt from
assuming that we are using C++11, and hence set `CMAKE_CXX_STANDARD` to
11, which will literally append `-std=gnu++11` to `CMAKE_CXX_FLAGS`.
the last `-std` option passed to `g++` takes precendence.
since we've switched over to C++17, and we are using C++17 features.
so, using cmake older than 3.8 breaks the build. because it is CMake 3.8
which stared support `CMAKE_CXX_STANDARD` 17.
- for bionic: https://packages.ubuntu.com/bionic/cmake : 3.10.2
- for CentOS7:
https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ : 3.13.5
so in this change,
* bump up the required version to v3.10.2
* cleanups to wipe out the workaround for lower CMake versions
* use `PROJECT_VERSION` defined by `project()` command instead of
`VERSION` explicitly defined.
Signed-off-by: Kefu Chai <kchai@redhat.com>
if `distutils_install_module("foo" ...)` is called mutiple times with
different python version, `foo-clone` will be added multiple times as a
custom target. which is not allowed:
add_custom_target cannot create target "foo-clone" because another
target with the same name already exists.
Signed-off-by: Kefu Chai <kchai@redhat.com>
allow `distutils_*()` functions to choose the python according to this
parameter, instead of implicitly using the variable of ${PYTHON_VERSION}
inherited from the caller.
Signed-off-by: Kefu Chai <kchai@redhat.com>
use the ones shiped from the latest cmake. which
* enables us to find the recent python intepreter and development files,
* find intepreter and development in a single `find_pacakge()` command,
simpler this way and less error prone.
and to accomodate this change:
* all `PYTHON${PYTHON_VERSION}_*` variables are renamed to
`Python${PYTHON_VERSION}_*` if we use `find_package(Python2...)` or
`find_package(Python3...)` to find python2 or python3 instead of using
`find_package(Python...)`.
* use "2" explicitly when using python2, as `Python_*` variables are not
defined anymore
* when compiling python support of ceph-mgr, continue using `Python_*`
variables. because we find the python interpreter and development
files using `find_pacakge(Python...)` for ceph-mgr.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this option was introduced by cmake 3.1, and we require cmake 3.5.1, so
we can use it without using the homebrew solution.
Signed-off-by: Kefu Chai <kchai@redhat.com>
use the combination of add_custom_command() and add_custom_target() to
build cython extensions to avoid rebuilding the cython extension
everytime we run "make"
Signed-off-by: Kefu Chai <kchai@redhat.com>
so add_custom_target() has better idea what is generated. if any target
will use it, it can be used as a dependency.
Signed-off-by: Kefu Chai <kchai@redhat.com>
The issue has been fixed upstream under lockfree commit
7e23dac52d08ed1a099de9a6fb8bcdefbb06d2da but is not yet available in
a boost release.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
* rename genl to nl:
"genl" is not very specific without more context. and libnl is actually
a library suite. so it would be better if we can rename the library to
be found to "libnl", and by following the naming convention of CMake,
in this change, Findgenl.cmake is renamed to Findnl.cmake
* Findnl.cmake: support the component argument, in our specific case,
what we want is "libnl-genl" library, which is one of the libraries
offered by libnl. so let's just make it a component.
* Findnl.cmake: should pass the names of the required variables instead of
their values to `find_package_handle_standard_args()`. before this
change, we pass `GENL_LIBRARIES` to this function. it was correct at the
first glance. but it is not able to handle the case where case where
libnl-genl is not installed. so the fix is to pass all the names of
required library paths to this function. in this change, their name
are concatenated to a single variable -- `nl_LIBRARIES`, and the
value of this variable is passed to
`find_package_handle_standard_args()`. and the error message would
be more specific this way if libnl-genl is not found:
Could NOT find nl (missing: nl_genl_LIBRARY)
* Findnl.cmake: add nl::<component> as imported library, it helps the
consumer of these libraries to import them -- no need to
specify the `target_include_directories()` separately anymore.
* move the find_package() code to where it is used. it helps to improve
the readability.
* remove `HAVE_GENL` variable: it's not used anywhere.
* drop the messages of "Not using foobar", they do not help.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* 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>