debian uses debian/tmp as destination dir for installing build files,
but since we are using common path($build_dir/external) available both
for rpm and debian based dependency installation, it becomes far more
complicated to maintain include/link path for these external projects.
elaborating on it:
path we are configuring for both rpm and debian installing including,
and linking of external librarires:
/build/ceph-17.0.0-5779-g928f9e55/obj-x86_64-linux-gnu/external/
debian appends DESTDIR to this path, and hence our predefined target
artificats cannot find correct path for external libs, I tried adding
ENV${DESTDIR} so that it could include correct external lib install
path, but it still cannot find them:
failed to link in case of:
- install(DIRECTORY $ENV{DESTDIR}${CMAKE_BINARY_DIR}/external/include/jaegertracing
- $ENV{DESTDIR}${CMAKE_BINARY_DIR}/external/include/opentracing
- DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
- include_directories(SYSTEM ${CMAKE_INSTALL_INCLUDEDIR}/jaegertracing)
- include_directories(SYSTEM ${CMAKE_INSTALL_INCLUDEDIR}/opentracing)
-- Installing: /build/ceph-17.0.0-5790-g6bc03cbd/debian/tmp/build/ceph-17.0.0-5790-g6bc03cbd/obj-x86_64-linux-gnu/external/include/jaegertracing/Tracer.h
cd /build/ceph-17.0.0-5790-g6bc03cbd/obj-x86_64-linux-gnu/src && /usr/bin/c++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/build/ceph-17.0.0-5790-g6bc03cbd/obj-x86_64-linux-gnu/src/include -I/build/ceph-17.0.0-5790-g6bc03cbd/src -isystem /build/ceph-17.0.0-5790-g6bc03cbd/obj-x86_64-linux-gnu/boost/include -isystem /build/ceph-17.0.0-5790-g6bc03cbd/obj-x86_64-linux-gnu/include -isystem /build/ceph-17.0.0-5790-g6bc03cbd/src/xxHash -isystem /build/ceph-17.0.0-5790-g6bc03cbd/src/rapidjson/include -isystem /build/ceph-17.0.0-5790-g6bc03cbd/src/include/jaegertracing -isystem /build/ceph-17.0.0-5790-g6bc03cbd/src/include/opentracing -g -O2 -fdebug-prefix-map=/build/ceph-17.0.0-5790-g6bc03cbd=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -o CMakeFiles/common-objs.dir/mds/mdstypes.cc.o -c /build/ceph-17.0.0-5790-g6bc03cbd/src/mds/mdstypes.cc
In file included from /build/ceph-17.0.0-5790-g6bc03cbd/src/osd/OpRequest.h:21,
from /build/ceph-17.0.0-5790-g6bc03cbd/src/osd/OpRequest.cc:3:
/build/ceph-17.0.0-5790-g6bc03cbd/src/common/tracer.h:10:10: fatal error: jaegertracing/Tracer.h: No such file or directory
Since the install path is in our build environment for these librarires,
skipping DESTDIR looks to me hacky fix, but does the job.
with empty destdir:
-- Installing: /build/ceph-17.0.0-5791-gb97b9640/obj-x86_64-linux-gnu/external/include/jaegertracing/Tracer.h
cd /build/ceph-17.0.0-5791-gb97b9640/obj-x86_64-linux-gnu/src/mon && /usr/bin/c++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/build/ceph-17.0.0-5791-gb97b9640/obj-x86_64-linux-gnu/src/include -I/build/ceph-17.0.0-5791-gb97b9640/src -isystem /build/ceph-17.0.0-5791-gb97b9640/obj-x86_64-linux-gnu/boost/include -isystem /build/ceph-17.0.0-5791-gb97b9640/obj-x86_64-linux-gnu/include -isystem /build/ceph-17.0.0-5791-gb97b9640/src/xxHash -isystem /build/ceph-17.0.0-5791-gb97b9640/src/rapidjson/include -isystem /build/ceph-17.0.0-5791-gb97b9640/obj-x86_64-linux-gnu/external/include -isystem /build/ceph-17.0.0-5791-gb97b9640/src/rocksdb/include -g -O2 -fdebug-prefix-map=/build/ceph-17.0.0-5791-gb97b9640=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -o CMakeFiles/mon.dir/MgrMonitor.cc.o -c /build/ceph-17.0.0-5791-gb97b9640/src/mon/MgrMonitor.cc
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
* adds BUILD_BYPRODUCT which tells ninja which library will be generated
after the build(needed for dependent build libs)
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
* Boost is a dependency for jaeger, to use the right version, we pass
ceph build boost path to cmake jaeger build step
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
since jaegertracing is the original target that jaeger submodule uses in
it's cmake, cmake build complained if named otherwise
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
set_library_properties_for_external_project assists with setting right target
properties for all jaeger dependencies.
IncludeJaeger would take care of linking and creating these targets
having them spread out when they are highly coupled seems not optimal.
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
adds Findthrift.cmake which is used to find thrift 0.13, as a dependency
for building jaegertracing
* bump up submodule version for jaeger-client-cpp for thrift compiler
removal
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
the change to build and ship libthift was added when we didn't have 0.13.0
version shipped via distro pkgs, now that centos 8 and F34 supports req.
version, we do not need to build and ship it with jaeger library.
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
* since focal and centos both have yaml-cpp 0.6 available, which dropped
having boost as it's dependency, moving to 0.6 seems a good upgrade.
* cmake: delete Buildyaml, since distro suppilies v0.6 this is not needed
This fixes the build failure, as jaegertracing requires yaml-cpp v0.6+
```
Could NOT find yaml-cpp: Found unsuitable version "", but required is at
least "0.5.1" (found yaml-cpp_LIBRARY-NOTFOUND)
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
* affects cmake builds for: yaml-cpp, thrift, jaeger, opentracing external
projects
changes done:
* artificat BUILD_BYPRODUCT which tells ninja which library will be generated
after the build(needed for dependent build libs)
* use cmake_command if `make` not found so that we use default generator, cmake
will identify and use ninja directly in this case.
* minor reorder of boost path in jaeger build external projet
fixes: https://tracker.ceph.com/issues/51029
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
since we've dropped the support of GCC older than v8.0, there is no need
to detect <experimental/filesystem>
Signed-off-by: Kefu Chai <kchai@redhat.com>
for better C++17 support, for instance for a better std::filesystem
support.
the reason why 8.1 is required is that ubuntu focal provides GCC-8.1,
and RHEL/CentOS8 provides GCC-8.4.1. so we only test the build on
GCC-8.1 and up so far.
Signed-off-by: Kefu Chai <kchai@redhat.com>
based on recent observation, quite a few C++ source file take
around more than 3.0GiB to compile. for instance,
test_mock_HttpClient.cc could take up to 6270MiB memory to compile.
so increase MAX_{LINK,COMPILE}_MEM accordingly.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this change make it more explicit how we override CC, CFLAGS and
CPPFLAGS:
* CC only for the compiler
* CFLAGS only for the flags consumed by C compiler
* CPPFLAGS only used for the preprocessor, it is used by both C and C++
compilers.
this change does not address any specific test failure. it just
improves the correctness and readability.
Signed-off-by: Kefu Chai <kchai@redhat.com>
the __asm__(".asmver ..") is a support provided by the compiler, so
would be better to detect it by either checking the compiler identifer
or just try it out.
in this change, instead of checking the building platform, we check this
feature using check_c_source_compiles().
in future, we could support versioned symbols using function attriubte
or symbol tables or version-script.
on platform where symbol versioning is not supported, we might need to
go with a different approach.
Signed-off-by: Kefu Chai <kchai@redhat.com>
the behavior of cmake 3.17 is a little bit different as it consider
NOT _library STREQUAL ""
as true, if ${_library} is "".
Signed-off-by: Kefu Chai <kchai@redhat.com>
to silence the warning like:
/home/jenkins-build/build/workspace/ceph-pull-requests/build/src/pybind/rados/rados.c: In function '__pyx_pymod_exec_rados':
/home/jenkins-build/build/workspace/ceph-pull-requests/build/src/pybind/rados/rados.c:78903:30: note: variable tracking size limit exceeded with '-fvar-tracking-assignments', retrying without
78903 | static CYTHON_SMALL_CODE int __pyx_pymod_exec_rados(PyObject *__pyx_pyinit_module)
| ^~~~~~~~~~~~~~~~~~~~~~
cc: warning: /usr/bin/cc: linker input file unused because linking not done
Signed-off-by: Kefu Chai <kchai@redhat.com>
since liburing's configure checks the CC and CXX env variables, let's
pass them when calling "configure". otherwise "make" still uses gcc and
g++ by default as they are specified in the "configure" script. this
also matches with the way how debian/rules calls "make".
Signed-off-by: Kefu Chai <kchai@redhat.com>
before this change, `pmem_VERSION_STRING` is not set if it is not able
to fulfill the specified version requirement. the intention was to check
if the version is able to satisfy the requirement. but actually, passing
an empty `pmem_VERSION_STRING` to `find_package_handle_standard_args()`
as the option of `VERSION_VAR` does not fail this check. on the
contrary, it prints
-- Found pmem: pmem_pmemobj_INCLUDE_DIR;pmem_pmem_INCLUDE_DIR (Required
is at least version "1.17")
if we requires pmem 1.17, while the found version is, for instance,
1.10.
if the required version is 1.7, and the found version is 1.10, the
output from cmake is:
-- Found pmem: pmem_pmemobj_INCLUDE_DIR;pmem_pmem_INCLUDE_DIR (found
suitable version "1.10", minimum required is "1.7")
in this change, the version spec is not specified when calling
`pkg_check_modules()`. so, `PKG_${component}_VERSION` is always set.
and we can always delegate the version checking to
`find_package_handle_standard_args()`. please note, we use the lower
version returned by pkg-config if multiple components are required and
both pkg-config settings return their versions.
Signed-off-by: Kefu Chai <kchai@redhat.com>
as FreeBSD also has msghdr but it does not have systemd, or
flags like MFD_ALLOW_SEALING, O_TMPFILE or F_SEAL_GROW. so
use WITH_SYSTEMD for enabling journald backend of logging system.
also move the option of "WITH_SYSTEMD" up so that the src/CMakeLists.txt
is able to see the variable of WITH_SYSTEMD defined by it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* cmake/modules/CephChecks.cmake: detect the existence of struct msghdr,
define HAVE_MSGHDR if it is found
* src/common/CMakeLists.txt: do not compile journald.cc if HAVE_MSGHDR
is FALSE. as in that case, we cannot use sendmsg() to write to
journald unix domain socket
* src/test/CMakeLists.txt, src/test/common/CMakeLists.txt: disable test
exercising journald logging backend if HAVE_MSGHDR is not defined
* src/common/Journald.h: define a dummy JournaldLogger and a dummy
JournaldClusterLogger when HAVE_MSGHDR is not defined, in order to
minimize the change in Log.h and Log.cc, otherwise the source code of
Log.h and Log.cc would be segmented into smaller chunks by
`ifdef HAVE_MSGHDR` macros.
* src/include/config-h.in.cmake: define a new macro named
HAVE_MSGHDR.
Signed-off-by: Kefu Chai <kchai@redhat.com>
detect the libpmem libraries' version using pkg-config
please note, the version is not identical to the ones defined in
libpmem.h or libpmemobj/base.h
Signed-off-by: Kefu Chai <kchai@redhat.com>
since we are moving the test nodes from bionic to focal, we are able to
use the prebuilt libzstd libraries when running "make check". to speed
up the build and test, in this change:
* add FindZstd.cmake which allows us to use the libzstd in system
* extract BuildZstd.cmake for better readability
* add an option named "WITH_SYSTEM_ZSTD", which defaults to "OFF",
so user can enable it on demand.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this allows us to pass extra argument to the script or executable to
further customize its behavior when testing.
also fix all the callers of add_ceph_unittest(), as there is no need to
repeat the executable, which is also used as the name of the test.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this change should allow us to decouple "ninja tests" from "ctest".
in other words, we can just run
ctest -R run-tox-python-common -V
without running "ninja tests" first. before this change
${name}-venv is added as a dependency of "tests" target.
after this change,
setup-venv-for-${name} is added as a test, which is in turn a test of
run-tox-${name}, so we can just
ctest -R run-tox-${name}
now for preparing the venv and then testing the tox test of ${name}.
Signed-off-by: Kefu Chai <kchai@redhat.com>
to limit the parallel level of compile jobs which consumes lots of memory
to compile and/or link.
compile following targets with heavy_compile_pool.
* unittest_librbd
* crimson*
* ceph-dencoder
some of the .cc files in the target above use up to 6 GiB memory to
compile.
Signed-off-by: Kefu Chai <kchai@redhat.com>
This is a complete rewrite on top of SimpleRADOSStriper as well as the
API. The VFS is now a loadable extension as well.
Fixes: https://tracker.ceph.com/issues/40609
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
the vanilla FindBoost.cmake pulled from cmake has couple assumptions
which do not hold in our environment. so address them case by case.
Signed-off-by: Kefu Chai <kchai@redhat.com>
git warns us when the repo is in 'detached HEAD' state, like:
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in
this state without impacting any branches by switching back to a branch.
...
Turn off this advice by setting config variable advice.detachedHead to
false
Signed-off-by: Kefu Chai <kchai@redhat.com>
libpmemobj should link against libpmem, but, in CMake, imported library
does not allow PRIVATE linkage. so pmem::pmem is added to the list of
INTERFACE_LINK_LIBRARIES.
Signed-off-by: Kefu Chai <kchai@redhat.com>
add two components: pmem and pmemobj to this package. so we can find
them and link against them in a more intuitive way.
before this change the COMPONENTS parameter passed to
find_package(pmem ...)
is dropped on the floor and ignored.
after this change, it is checked and taken into consideration.
also, in this change, the exposed variables are renamed from
PMEM_* to pmem_*
to be consistent with the package name. it's encouraged to be consistent
with the package name when it comes to the INCLUDE_DIR and LIBRARIES
variable names.
Signed-off-by: Kefu Chai <kchai@redhat.com>
to address the warning from cmake, like
CMake Warning (dev) at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273 (message):
The package name passed to `find_package_handle_standard_args` (numa) does
not match the name of the calling package (NUMA). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Signed-off-by: Kefu Chai <kchai@redhat.com>
RocksDB's cmake has a similar logic to turn on ccache as the main cmake.
Currently BuildRocksDB.cmake explicitly passes ccache to RocksDB cmake
arguments as CMAKE_CXX_COMPILER_LAUNCHER. This causes a compilation error
on ccache 4.0, especially in make -j mode.
ccache: error: Recursive invocation (the name of the ccache binary must
be "ccache")
This commit lets cmake from RocksDB decide RULE_LAUNCH_COMPILE by itself.
Signed-off-by: Sheng Mao <shngmao@gmail.com>
if nasm is able to emit AVX512 instructions, we can assume that it's
able to generate AVX2 instructions as well. so no need to print "Found
nasm" multiple times.
and by chaining mutual exclusive branches with "elseif", we can have
better readability.
Signed-off-by: Kefu Chai <kchai@redhat.com>
not_arch_x32 replicates ${_support_x64}. and a variable starts with
"not" is just difficult to parse. so drop it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
it's reported that on Alphine, "make install" installs
`ceph-volume-systemd` into `/usr/bin` instead of `/usr/sbin`, and this
breaks `systemd/ceph-volume@.service`. so in this change, we always
install this script into `/usr/sbin`, even if `DESTDIR` is not defined.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* This commit introduces Jaegertracing library as package libjaeger,
pickwhich would be consumed by other ceph pacakges such as ceph-common0
* adds the following dependencies, which would be build from source
using ExternalProjectHelper.cmake +IncludeJaeger.cmake +
Build<package>.cmake scripts:
jaegertracing: v0.6.0 [added as a submodule]
opentracing: v1.6.0 [added as a submodule]
thrift: 0.13.0 [added as a submodule]
yaml-cpp: 0.6.0
json(optional)
* updates Boost to be installed instead of being build only, because
jaegertracing them during their build process.
* ceph.spec.in: introduces a default enabled jaeger packaging option,
which could be disabled using --without-jaeger flag during rpmbuild
* note: libjaeger package if enabled will be a dependency on ceph-common, ceph-mon, rgw_common and transitively will be a dependency for modules that have them as a dependency.
Signed-off-by: Deepika Upadhyay <dupadhya@redhat.com>
test/crimson: do not link against crimson-{os,common}
Reviewed-by: Samuel Just <sjust@redhat.com>
Reviewed-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
this change was originally introduced as a part of
418bfd7bb5, and latter migrated / changed
in the current form. but the idea is the same: to rebuild rocksdb even
if the stamp file shows that it has been built. there is no need to do
so, as we don't hack RocksDB as we used to. also,it is distracting to
check this log message when rebuilding the tree. so drop it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
https://git.kernel.dk/liburing appears, at least currently, to be
unavailable. This could be reverted once it comes back.
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
since GCC-9
> Using the types and functions in <filesystem> does not require linking
> with -lstdc++fs now.
see https://gcc.gnu.org/gcc-9/changes.html#libstdcxx
Signed-off-by: Kefu Chai <kchai@redhat.com>
Currently the configure script is run on 'liburing_ext' not only for the
initial build but for subsequent incremental builds.
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
This commit introduces internal (not yet part of the api) librbd functions for:
1. formating an RBD image in LUKS format
2. parsing an RBD image in LUKS format
The actual implementation of the LUKS format is done via libcryptsetup, which is added as a new dependency.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
silence "detached HEAD" warning like:
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
Signed-off-by: Kefu Chai <kchai@redhat.com>
in liburing,
75cad68b95
partially reverts
4e360f7113,
which builds liburing.a with -fPIC.
so we need to pass -fPIC by ourselves. otherwise we'd have
/usr/bin/ld: ../../liburing/src/liburing.a(setup.ol): relocation R_X86_64_PC32 against symbol `io_uring_queue_mmap' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
src/test/fio/CMakeFiles/fio_ceph_objectstore.dir/build.make:154: recipe for target 'lib/libfio_ceph_objectstore.so' failed
Signed-off-by: Kefu Chai <kchai@redhat.com>
we cannot assume that user uses "make" as the generator of cmake, if,
for instance, ninja is used, `$(MAKE)` is not a valid variable in the
generated `build.ninja`. so we should use "make" explicitly.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* GIT_SHALLOW=TRUE, so we don't pull the full git history,
as we don't care about it.
* UPDATE_DISCONNECTED=TRUE, to skip the UPDATE step, this change
somehow works around
https://gitlab.kitware.com/cmake/cmake/-/issues/19703. otherwise
cmake keeps building liburing.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* use functions exposed by liburing instead of using syscalls
* v0.7 is the latest release at the time of writing, as liburing is under
active development. it'd be better to use a newer release.
* also use https://git.kernel.dk/liburing instead of
http://git.kernel.dk/liburing.
Signed-off-by: Kefu Chai <kchai@redhat.com>
before this change add_tox_test() always add "py3" to testenv, even the
caller specifies TOX_ENVS explicitly.
after this change, py3 is added only if the caller does not specify any
TOX_ENVS.
this change helps with the readability.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Libzbc maintainers recommend switching to libzbd, which is lighter and supports
both ZNS SSDs and HM-SMR HDDs.
Signed-off-by: Abutalib Aghayev <agayev@cs.cmu.edu>
sys_siglist is deprecated with glibc 2.32. A new thread-safe and
async-signal safe sigdescr_np() function is provided, so use it if
available.
Fixes: https://tracker.ceph.com/issues/47187
Signed-off-by: David Disseldorp <ddiss@suse.de>
* cmake/modules/FindSanitizers.cmake: do not pollute CMAKE_REQUIRED_FLAGS
* cmake/modules/FindSanitizers.cmake: expose Sanitizers_COMPILE_OPTIONS
as a list
* CMakeLists.txt: append Sanitizers_COMPILE_OPTIONS to
*_LINKER_FLAGS after replacing ";" with " " in it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
instead of sticking to the building host's march (native), use a safer
guess.
Fixes: https://tracker.ceph.com/issues/24948
Signed-off-by: Kefu Chai <kchai@redhat.com>
on the newest DPDK/SPDK some libraries were removed, while some of them
were added. so update the list accordingly to address linking errors.
Signed-off-by: Roman Penyaev <rpenyaev@suse.de>
git complains when checking out a tag in "detached HEAD", like:
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them
...
but this does not help, as, in general, we don't hack fio in Ceph,
so disable this warning. and also clone the repo in shallow mode
for the same reason -- we don't care about the whole history of
fio repo. we just use it for testing.
Signed-off-by: Kefu Chai <kchai@redhat.com>
For things like cephadm, where there is a lot of "from X import Y",
the import tags become cumbersome. .tox dirs and
python-common/build are just repeats of source files found elsewhere
so result in duplicate tags
Signed-off-by: Dan Mick <dmick@redhat.com>
Recent RocksDB version use slightly different parameter names for
the LZ4 include/lib dirs, we'll have to pass the right ones.
We'll also have to fix the "CMAKE_TOOLCHAIN_FILE" parameter,
which isn't passed properly.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
instead of appending compile flags to CMAKE_C_FLAGS, use
add_compile_options(), as COMPILE_OPTIONS is a list, it'd simpler to
append options to it and to access it in a structured way.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* refs/pull/34719/head:
ceph-fuse: compatible with libfuse3.5 or higher
cmake: to get the header and library from specified path
libfuse: check the libfuse version from the pkconfig/fuse{3}.pc file
Reviewed-by: Zheng Yan <zyan@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
Since the pkg_search_module will help us set the header and lib
path, which we should get the headers and lib from. To check from
other paths will make no sense.
Fixes: https://tracker.ceph.com/issues/45396
Signed-off-by: Xiubo Li <xiubli@redhat.com>
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>
