By default ceph builds the bundled src/spdk fork via BuildSPDK. Add a
WITH_SYSTEM_SPDK option that instead locates a distro-provided SPDK
through a new Findspdk.cmake (pkg-config based, modelled on
Finddpdk.cmake), exposing the same spdk::spdk target.
Signed-off-by: Sun Yuechi <sunyuechi@iscas.ac.cn>
AddCephTest.cmake links the bare target names Catch2 / Catch2WithMain.
With WITH_SYSTEM_CATCH2=ON, CPM resolves Catch2 via find_package(),
which only exports the namespaced IMPORTED targets Catch2::Catch2 /
Catch2::Catch2WithMain. CMake then treats the bare names as plain
library names and the link fails with -lCatch2WithMain, since the
physical library is named libCatch2Main (OUTPUT_NAME "Catch2Main").
Use the namespaced names. Catch2 exports them as ALIASes in the bundled
(CPM subproject) build too, so the default path keeps working.
Signed-off-by: Sun Yuechi <sunyuechi@iscas.ac.cn>
When WITH_SYSTEM_ARROW is false, Ceph builds Arrow from the bundled
src/apache submodule. Our CI uses ubuntu:jammy as the base image, which
does not package libarrow-dev, so the bundled path is always taken there.
Arrow 17.0.0 vendors a copy of Thrift whose download URLs are no longer
reachable, breaking CI builds that try to fetch them at configure time.
Bump arrow submodule to 19.0.1, the latest Arrow release that:
- builds successfully on ubuntu:jammy, and
- requires only CMake 3.22 (the version shipped by ubuntu:jammy)
See also
CMake version shipped by ubuntu:jammy
- https://packages.ubuntu.com/jammy/cmake
arrow releases' CMake support
- maint-19.0.1: 272715f6df/cpp/CMakeLists.txt (L18)
- maint-20.0.0: 3ad0370a04/cpp/CMakeLists.txt (L18)
arrow enabled minmalloc by default
-
b907c5dadb
Because arrow uses the bundled mialloc library be default, we need
to disable it in the same commit bumping up the submodule.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
- Add crc32_iscsi_by16_10 in src/isa-l into candidates for ceph_crc32c
- Add hardware capability check for AVX512 instr before register
- Add NASM feature check to ensure compatibility and to enable
AS_FEATURE_LEVEL in crc32_iscsi_by16_10.asm
Signed-off-by: Maodi Ma <mamaodi@hygon.cn>
Skip building the igzip executables; Ceph only needs libisal.la.
This should speed up the build a little bit, as we don't build the
executables previous built with "make"
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Time is marching on and the state of the art with python packaging has
not stood still. In Python 3.12, distutils has been removed after being
deprecated for a couple of versions. According to the Python Packaging
User Guide [1]: "However, `python setup.py` and the use of `setup.py` as a
command line tool are deprecated."
Currently, ceph provides a decent sized and growing library of python
code in `src/python-common/ceph`. It currently relies on `setup.py` and
the deprecated `python setup.py install` command. This change aims to be
the first step in moving toward a more contemporary approach so that we
don't get caught late when the older approaches really stop working.
Because ceph's primary diver of "build stuff" is CMake, there was an
existing `cmake/modules/Distutils.cmake` that invokes a `python setup.py
install` command. Rather than risk breaking older distros we add a new
`cmake/modules/PythonPackage.cmake` file that uses the PEP 517/518
[2][3] style
of packaging. I could not find some existing CMake support for this
so unfortunately I had to write this.
The approach taken is loosely based on what the rpm build process does.
It invokes pip's wheel subcommand to build a wheel (during the build
phase) and then uses pip to install the wheel to install the content
to the system.
A future commit will add conditional support for using this approach
in src/python-common.
[1] https://packaging.python.org/en/latest/discussions/setup-py-deprecated/
[2] https://peps.python.org/pep-0517/
[3] https://peps.python.org/pep-0518/
Signed-off-by: John Mulligan <jmulligan@redhat.com>
A typo in CFLAGS means we're passing an empty string to configure_cmd.
We are then overwriting the build environment CFLAGS with our empty string CFLAGS,
which can result in build failures in certain environments, as seen in the tracker.
This fix gets any build environment CFLAGS and appends the other flags
we want to use when building ISA-L 2.32.0
Fixes: https://tracker.ceph.com/issues/76389
Signed-off-by: Jamie Pryde <jamiepry@uk.ibm.com>
location.
This is to fix the following libec_isa.si build error :
FAILED: lib/libec_isa.so
: && /usr/bin/g++-14 -fPIC -O3 -DNDEBUG
-Wl,--dependency-file=src/erasure-code/isa/CMakeFiles/ec_isa.dir/link.d
-shared -Wl,-soname,libec_isa.so -o lib/libec_isa.so
src/erasure-code/CMakeFiles/erasure_code_objs.dir/ErasureCode.cc.o
src/erasure-code/isa/CMakeFiles/ec_isa.dir/ErasureCodeIsa.cc.o
src/erasure-code/isa/CMakeFiles/ec_isa.dir/ErasureCodeIsaTableCache.cc.o
src/erasure-code/isa/CMakeFiles/ec_isa.dir/ErasureCodePluginIsa.cc.o
src/isa-l/install/lib/libisal.a -ldl /usr/lib64/librt.a -lresolv
-Wl,--as-needed -latomic && :
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld:
cannot find src/isa-l/install/lib/libisal.a: No such file or directory
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
It looks like [under some circumstances?] the building procedure puts
resulting .a under src/isa-l/install/lib64 path which causes lookup
error .so linkage.
This patch enforces lib64 usage.
Signed-off-by: Igor Fedotov <igor.fedotov@croit.io>
Add a cmake option to build ceph's erasure code plugins (ec_jerasure
and ec_shec) against system-provided jerasure and gf-complete libraries
instead of the vendored copies.
This allows downstream distributions to build with their own packaged
versions of these libraries. For instance, Debian has shipped
libjerasure-dev and libgf-complete-dev as build dependencies for ceph
since 2021, but the build always used the vendored copies because there
was no cmake option to use the system ones.
Using system libraries also lets distributions benefit from any
optimizations or fixes applied to their packages without having to
carry patches against ceph's vendored copies. For example, the vendored
gf-complete requires a downstream -O1 workaround to avoid emitting
SSE 4.1 instructions that crash on older CPUs. But with system libraries,
that becomes the library package's responsibility.
The option is OFF by default, preserving the current behavior of
building from vendored sources.
A new FindJerasure.cmake module locates the system jerasure and
gf-complete headers and libraries, and creates the Jerasure::jerasure
imported target with the same target name that the vendored build now
provides (see previous commit).
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
This adds hardware-accelerated crc32c support for the RISC-V
architecture. It includes the feature implementation, necessary
CMake configuration, and plumbing in src/arch/riscv.c to correctly
detect and select the optimized instructions.
Signed-off-by: lvshuo2016 <lv.shuo@sanechips.com.cn>
ISA-L 2.31.0 introduced new EC functions that use SVE instructions on aarch64.
This means that the assembler must support SVE instructions
to build for aarch64. This commit passes `-Wa,-march=armv8-a+sve` to the ISA-L
configure step so the external assembler can process the new .S and .c files.
Signed-off-by: Jamie Pryde <jamiepry@uk.ibm.com>
As of Clang 21, -fsanitize=undefined no longer implies vptr.
This adds vptr as an explicit component and provides the necessary compile options to satisfy Seastar's build requirements.
See: c1060ea7d4 for more details
Signed-off-by: Aishwarya Mathuria <amathuri@redhat.com>
Replace 'setup.py install' with 'pip install --use-pep517' to fix
Cython compilation failures and eliminate deprecation warnings.
Problem Statement:
The build process for Cython modules involves preprocessing .pyx files
(e.g., generating rbd_processed.pyx from rbd.pyx) and then cythonizing
with specific compiler_directives. The previous approach using separate
'setup.py build' and 'setup.py install' commands caused this failure:
```
Error compiling Cython file:
------------------------------------------------------------
...
"""
name = cstr(name, 'name')
cdef:
rados_ioctx_t _ioctx = convert_ioctx(ioctx)
char *_name = name
librbd_progress_fn_t _prog_cb = &no_op_progress_callback
^
------------------------------------------------------------
rbd_processed.pyx:781:44: Cannot assign type 'int (*)(uint64_t, uint64_t, void *) except? -1' to 'librbd_progress_fn_t'. Exception values are incompatible. Suggest adding 'noexcept' to type 'int (uint64_t, uint64_t, void *) except? -1'.
```
This occurs because:
1. 'setup.py build build_ext' successfully preprocesses and cythonizes
with compiler_directives from setup.py's cythonize() call
2. 'setup.py install' internally triggers a rebuild that:
- Regenerates the preprocessed .pyx files
- Re-runs cythonize() through Cython.Distutils.build_ext
- Does NOT apply the compiler_directives from setup.py
- Fails on the regenerated files missing required directives
New Options Explained:
`--use-pep517`:
Addresses deprecation warning:
```
DEPRECATION: Building 'rados' using the legacy setup.py bdist_wheel
mechanism, which will be removed in a future version. pip 25.3 will
enforce this behaviour change.
```
Uses the modern PEP 517 build backend which:
- Performs a single build pass with all compiler_directives applied
- Prevents the implicit rebuild that caused CompileError
- Future-proofs against pip 25.3+ which will require this
`--no-build-isolation`:
Ensures that environment variables set by CMake are respected:
- CC, LDSHARED (compiler toolchain)
- CPPFLAGS, LDFLAGS (compilation flags)
- CYTHON_BUILD_DIR, CEPH_LIBDIR (build paths)
Without this flag, pip would create an isolated build environment
that ignores these critical build settings.
`--no-deps`:
Prevents pip from attempting to install Python dependencies listed
in setup.py's install_requires. All dependencies are managed by
CMake and the distribution's package manager, not pip.
`--ignore-installed`:
Addresses installation error when DESTDIR is set:
```
ERROR: Could not install packages due to an OSError: [Errno 13]
Permission denied: '/usr/lib/python3/dist-packages/rados-2.0.0.egg-info'
OSError: [Errno 18] Invalid cross-device link:
'/usr/lib/python3/dist-packages/rados-2.0.0.egg-info' -> '/tmp/pip-uninstall-...'
```
This error occurs because pip detects an existing system installation
and tries to uninstall it before installing to DESTDIR. With
--ignore-installed, pip skips the uninstall step and directly installs
to the DESTDIR staging directory, which is the correct behavior for
packaging.
Removed Options:
`--install-layout=deb`:
This Debian-specific patch to 'setup.py install' is no longer needed.
Modern pip automatically detects the distribution and uses the correct
layout (dist-packages on Debian, site-packages on RPM distros).
`--single-version-externally-managed`:
This option was specific to 'setup.py install' to prevent egg
installation. With pip, this is handled automatically.
`--record /dev/null`:
No longer needed as pip manages installation records internally.
`egg_info --egg-base`:
Not needed with pip as metadata is generated automatically during
the build process.
Not added option:
`--root-user-action=ignore`: not added
In this change, we installing a python module using pip with
`fakeroot` before packaging it. But pip warned:
```
Error: WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behavior with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
```
But we use fakeroot on purpose, this option could have been added to
silence this warning. But it is not available in all supported pip
versions. see
2e1112a814
New environmental variable:
`DEB_PYTHON_INSTALL_LAYOUT=deb` is conditionally applied when packaging
for debian-derivative distributions. As pip does not support
`--install-layout` option. Since debian patches pip so it installs Python
modules into /usr/local/lib instead of /usr/lib where debian dh_install
helper looks for the content to be packaged, so we have to enforce the
debian layout using the environmental variable.
Working Directory Change:
Changed from `CMAKE_CURRENT_SOURCE_DIR` to `CMAKE_CURRENT_BINARY_DIR` to
keep pip's temporary files and logs in the build directory rather than
polluting the source tree.
Additional Dependencies:
Since the build process uses pip and creates a wheel distribution,
we need to add `pip` and `wheel` Python modules as build dependencies.
Python moduels packaging:
- with `--use-pep517`, pip creates .dist-info directoires as per PEP-517
instead of .egg-info, so we need to package the new metadata directory.
Future Improvements
We considered implementing a custom `build_templates` command or using
setuptools' `sub_commands` mechanism to avoid regenerating `*_processed.pyx`
files on every build (tracking dependencies via file modification times or
hash-based checks). However, to keep `setup.py` simple and maintainable,
we've deferred this optimization for future work. The current solution
using `pip install --use-pep517` ensures correct builds without additional
complexity.
This solution works correctly for both Debian and RPM packaging workflows,
both of which use DESTDIR-based staged installations.
Fixes: 719b749846
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
This is bundled with modern cmake and we no longer use Ubuntu Focal as
our minimum, so we can stop carrying this.
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
The distutils_install_cython_module() function was using ${PY_LDFLAGS}
without defining it, causing the linker to fail with:
/opt/rh/gcc-toolset-13/root/usr/libexec/gcc/x86_64-redhat-linux/13/ld:
cannot find -lrados: No such file or directory
This bug was introduced in commit d22734f6cb which changed:
set(ENV{LDFLAGS} "-L${CMAKE_LIBRARY_OUTPUT_DIRECTORY}")
to:
set(ENV{LDFLAGS} "${PY_LDFLAGS}")
However, PY_LDFLAGS was only defined in distutils_add_cython_module(),
not in distutils_install_cython_module(). This meant that during the
install phase, LDFLAGS was set to an empty string, and the linker
couldn't find librados.so and other Ceph libraries in the build
directory.
The bug was exposed by commit 719b749846
which changed rados.pxd to use C preprocessor conditionals (#ifdef
BUILD_DOC) instead of Cython's compile-time IF statements. This meant
the build now required proper linking during the install phase.
Fix by defining PY_LDFLAGS in distutils_install_cython_module():
set(PY_LDFLAGS "${CMAKE_SHARED_LINKER_FLAGS} -L${CMAKE_LIBRARY_OUTPUT_DIRECTORY}")
This keeps CMAKE_SHARED_LINKER_FLAGS as a space-separated string and
appends the library directory flag, avoiding issues with semicolon
conversion.
Fixes: d22734f6cb
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Boost has included this since 1.70 and CMake has deprecated the
non-config version since 3.30.
See also
https://cmake.org/cmake/help/latest/policy/CMP0167.html#policy:CMP0167
We enable CMP0167 (The `FindBoost` module is removed.) to force cmake
to use the installed Boost configuration files rather than its own
detection.
We also enable CMP0144 (`find_package()` uses upper-case
`<PACKAGENAME>_ROOT` variables.) to ensue that the `BOOST_ROOT`
parameter continues to function in the config-style `find_package`.
`BuildBoost.cmake` is updated to add the `Boost::headers` interface
target to match configured system boost (retaining the Boost::boost
alias).
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
The current add_executable override in Boost does not support alias
targets. Although Ceph currently has no alias targets that are
affected by this limitation, addressing this issue now will benefit
future developments and personal projects.
This change enhances the robustness of the override logic, ensuring
compatibility with alias targets moving forward.
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
This change improves the CMAKE variable detection logic in do_cmake.sh
to allow users to override the CMAKE binary used for building.
Changes:
- Add conditional check to only set CMAKE if not already set
- Add detection for cmake version 4.x and later (prioritized)
- Maintain backward compatibility with cmake3 fallback
- Allow users to specify custom CMAKE path via environment variable
- Pass CMAKE_POLICY_VERSION_MINIMUM if set to submodule build steps for
older modules
This enables users to use a specific cmake binary by setting the CMAKE
environment variable before running the script:
CMAKE=/custom/path/to/cmake ./do_cmake.sh
Additionally, the script now automatically detects and uses cmake 4.x+
when available, falling back to cmake3 or cmake as needed. This supports
building Ceph with newer cmake versions while maintaining compatibility
with existing build environments.
Fixes: https://tracker.ceph.com/issues/73523
Signed-off-by: Edwin Rodriguez <edwin.rodriguez1@ibm.com>
the bump to arrow 17.0.0 broke the ubuntu jammy builds with:
In file included from /usr/include/thrift/transport/TTransport.h:25,
from /usr/include/thrift/protocol/TProtocol.h:28,
from /usr/include/thrift/TBase.h:24,
from /build/ceph-20.3.0-3599-g3d863d32/src/arrow/cpp/src/generated/parquet_types.h:14,
from /build/ceph-20.3.0-3599-g3d863d32/src/arrow/cpp/src/generated/parquet_constants.h:10,
from /build/ceph-20.3.0-3599-g3d863d32/src/arrow/cpp/src/generated/parquet_constants.cpp:7:
/usr/include/thrift/transport/TTransportException.h:23:10: fatal error: boost/numeric/conversion/cast.hpp: No such file or directory
23 | #include <boost/numeric/conversion/cast.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
when comparing the gcc command line with arrow-15.0.0, the following argument
is no longer present:
> -isystem /build/ceph-20.3.0-3402-gb2db4947/obj-x86_64-linux-gnu/boost/include
arrow 17.0.0 seems to assume that thrift doesn't depend on boost anymore. a
comment in https://github.com/apache/arrow/issues/32266 claims that
> we don't need Boost with system Thrift 0.17.0 or later
but our jammy builds are stuck with libthrift-0.16.0. to reenable jammy builds,
instruct Arrow's cmake to use its bundled thrift dependency if our system thrift
version is < 0.17.0
Signed-off-by: Casey Bodley <cbodley@redhat.com>
when thrift headers are found, parse the version string into a
cmake variable and pass it to find_package_handle_standard_args
this will be needed by BuildArrow.cmake for some conditional logic
Signed-off-by: Casey Bodley <cbodley@redhat.com>
Arrow requires xsimd >= 9.0.1 according to arrow/cpp/thirdparty/versions.txt.
Previously, we unconditionally set -Dxsimd_SOURCE=BUNDLED, forcing the use
of Arrow's vendored xsimd regardless of system package availability.
This commit changes to -Dxsimd_SOURCE=AUTO, which allows Arrow's
resolve_dependency mechanism to automatically:
1. Try to find system xsimd package
2. Check if version >= 9.0.1
3. Use system version if found and sufficient
4. Fall back to bundled version otherwise
This reduces build time and dependencies on systems with sufficient xsimd,
while maintaining compatibility with older distributions.
Distribution availability:
- Ubuntu Noble (24.04): libxsimd-dev 12.1.1 (✓ will use system)
- Ubuntu Jammy (22.04): libxsimd-dev 7.6.0 (✗ will use bundled)
- Debian Trixie (13): libxsimd-dev 13.2.0 (✓ will use system)
- CentOS Stream 9: xsimd-devel 7.4.9 (✗ will use bundled)
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Add a pair of default test labels (`PurePython` and `PythonTox`) to the
tests generated by the add_tox_test cmake function. In addition, the
function can extend the set of labels applied with a new LABELS argument
to the cmake function.
Using the label can be done with something like:
```
ctest -L PythonTox -j8
```
Note that these tests are labeled PurePython because they do not
require C extensions to be built. The above example command can
be run successfully immediately after configuring, without having
to build the C++ sources first.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add suppression rules for two categories of false positive warnings
encountered during ASan-enabled testing:
1. PyModule_ExecDef memory leaks: ASan incorrectly interprets Python's
module loading behavior as memory leaks when the interpreter loads
extension modules.
2. __cxa_throw interception failures: ASan's interceptor cannot properly
intercept exception handling when libstdc++.so is loaded after the
ASan shared library, causing CHECK failures.
3. ErasureCodePluginRegistry::load:
`ceph::ErasureCodePluginRegistry::load()` is known to leak, as we
don't free the memory allocated by the ec plugins which are
registered in the `ErasureCodePluginRegistry` singleton. this is a
known issue, but since the `ErasureCodePluginRegistry` instance is a
singleton. we can live with it. in this change, we add the rule to
suppress the leak report from LeakSanitizer. this rule also exist in
qa/valgrind.supp.
All warnings are confirmed false positives that should be suppressed
to reduce noise in test output.
Example warnings:
```
Direct leak of 3264 byte(s) in 1 object(s) allocated from:
#0 0x7f6027d20cb5 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
#1 0x7f60277557ad (/usr/lib/libpython3.13.so.1.0+0x1557ad) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#2 0x7f6027756067 (/usr/lib/libpython3.13.so.1.0+0x156067) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#3 0x7f60278471a0 (/usr/lib/libpython3.13.so.1.0+0x2471a0) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#4 0x7f602774d031 (/usr/lib/libpython3.13.so.1.0+0x14d031) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#5 0x7b60234093bb in __Pyx_modinit_type_init_code.constprop.0 /home/kefu/dev/ceph/build/src/pybind/rados/rados.c:82066
#6 0x7b602340a826 in __pyx_pymod_exec_rados /home/kefu/dev/ceph/build/src/pybind/rados/rados.c:82755
#7 0x7f6027856777 in PyModule_ExecDef (/usr/lib/libpython3.13.so.1.0+0x256777) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#8 0x7f602785baa3 (/usr/lib/libpython3.13.so.1.0+0x25baa3) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#9 0x7f6027793df2 (/usr/lib/libpython3.13.so.1.0+0x193df2) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#10 0x7f6027777cbe in _PyEval_EvalFrameDefault (/usr/lib/libpython3.13.so.1.0+0x177cbe) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#11 0x7f60277957de (/usr/lib/libpython3.13.so.1.0+0x1957de) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#12 0x7f60277d11b9 in PyObject_CallMethodObjArgs (/usr/lib/libpython3.13.so.1.0+0x1d11b9) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#13 0x7f60277d0ee4 in PyImport_ImportModuleLevelObject (/usr/lib/libpython3.13.so.1.0+0x1d0ee4) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#14 0x7f6027779c0c in _PyEval_EvalFrameDefault (/usr/lib/libpython3.13.so.1.0+0x179c0c) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#15 0x7f602784e2c8 in PyEval_EvalCode (/usr/lib/libpython3.13.so.1.0+0x24e2c8) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#16 0x7f602788c88b (/usr/lib/libpython3.13.so.1.0+0x28c88b) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#17 0x7f602788985c (/usr/lib/libpython3.13.so.1.0+0x28985c) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#18 0x7f6027886f57 (/usr/lib/libpython3.13.so.1.0+0x286f57) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#19 0x7f6027886211 (/usr/lib/libpython3.13.so.1.0+0x286211) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#20 0x7f6027885b82 (/usr/lib/libpython3.13.so.1.0+0x285b82) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#21 0x7f6027883e50 in Py_RunMain (/usr/lib/libpython3.13.so.1.0+0x283e50) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#22 0x7f602783bbea in Py_BytesMain (/usr/lib/libpython3.13.so.1.0+0x23bbea) (BuildId: bea05fc2c8bd66145b159f10dcd810ebe813af39)
#23 0x7f6027227674 (/usr/lib/libc.so.6+0x27674) (BuildId: 4fe011c94a88e8aeb6f2201b9eb369f42b4a1e9e)
#24 0x7f6027227728 in __libc_start_main (/usr/lib/libc.so.6+0x27728) (BuildId: 4fe011c94a88e8aeb6f2201b9eb369f42b4a1e9e)
#25 0x55dae17e6044 in _start (/usr/bin/python3.13+0x1044) (BuildId: 8c0dc848f5b978c56ebeb07255bb332b4b37ae4e)
```
```
AddressSanitizer: CHECK failed: asan_interceptors.cpp:335 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0) (tid=3246455)
#0 0x7f345ea81979 in CheckUnwind ../../../../src/libsanitizer/asan/asan_rtl.cpp:69
#1 0x7f345eaa790d in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86
#2 0x7f345e9e1d54 in __interceptor___cxa_throw ../../../../src/libsanitizer/asan/asan_interceptors.cpp:335
#3 0x7f345e9e1d54 in __interceptor___cxa_throw ../../../../src/libsanitizer/asan/asan_interceptors.cpp:334
#4 0x7f3458623def in void boost::throw_exception<boost::bad_lexical_cast>(boost::bad_lexical_cast const&) /opt/ceph/include/boost/throw_exception.hpp:165
#5 0x7f345997ad3b in void boost::conversion::detail::throw_bad_cast<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned long>() /opt/ceph/include/boost/lexical_cast/bad_lexical_cast.hpp:93
#6 0x7f3459979d35 in unsigned long boost::lexical_cast<unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /opt/ceph/include/boost/lexical_cast.hpp:43`
```
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
LeakSanitizer prints matched suppressions by default, which causes CLI
tests to fail when built with LSan enabled. The tests compare actual
output against expected output, and the additional LSan messages break
this comparison.
Example failure:
```
/home/jenkins-build/build/workspace/ceph-pull-requests/src/test/cli/ceph-kvstore-tool/help.t: failed
--- /home/jenkins-build/build/workspace/ceph-pull-requests/src/test/cli/ceph-kvstore-tool/help.t
+++ /home/jenkins-build/build/workspace/ceph-pull-requests/src/test/cli/ceph-kvstore-tool/help.t.err
@@ -21,3 +21,9 @@
stats
histogram [prefix]
+ -----------------------------------------------------
+ Suppressions used:
+ count bytes template
+ 1 45 ^MallocExtension::Initialize
+ -----------------------------------------------------
+
```
Set LSAN_OPTIONS=print_suppressions=0 to prevent this output rather
than modifying test expectations, since the suppression messages are
not part of the actual tool output and would vary between builds.
This change should fix run_cli_tests failures when building with LeakSanitizer
See https://github.com/google/sanitizers/wiki/SanitizerCommonFlags
for the environment variables respected by LeakSanitizer.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
Add Boost 1.88.0 to the supported versions list and update component
dependencies to eliminate build warnings.
This resolves the following warning when building with Boost 1.88.0:
```
-- Found Boost: /usr/include (found suitable version "1.88.0", minimum required is "1.73.0")
CMake Warning at cmake/modules/FindBoost.cmake:1413 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
Call Stack (most recent call first):
cmake/modules/FindBoost.cmake:1538 (_Boost_COMPONENT_DEPENDENCIES)
cmake/modules/FindBoost.cmake:2157 (_Boost_MISSING_DEPENDENCIES)
src/CMakeLists.txt:461 (_find_package)
src/seastar/cmake/SeastarDependencies.cmake:136 (find_package)
src/seastar/CMakeLists.txt:395 (seastar_find_dependencies)
```
Boost 1.88.0 was released on April 3, 2025, and is already available
in some distributions. Since many distributions don't yet ship Boost's
native CMake configuration files, our vendored FindBoost.cmake module
needs updating to handle this version.
The component dependencies were updated following the scanning procedure
documented in the _Boost_COMPONENT_DEPENDENCIES() function. The change
will be upstreamed to CMake shortly.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
Update our local FindBoost.cmake module to match CMake upstream's
latest version to properly handle Boost component dependencies.
While commit b446290f prevented warnings when checking Boost 1.87,
it failed to update the boost component dependency mappings. This
change synchronizes our module with upstream to ensure correct
dependency resolution.
Additionally, this prepares for Boost 1.88.0 support (released
April 3, 2025) which some distributions have already adopted.
Since CMake upstream hasn't yet added 1.88 support, this sync
provides the foundation for adding 1.88.0 compatibility in a
subsequent commit.
Changes made:
- Sync with upstream CMake FindBoost.cmake (commit 17726227)
(at 1772622772/Modules/FindBoost.cmake)
- Reapply local modifications from commit 06824bc1
Note: New dependencies can be scanned using:
```
cmake -DBOOST_DIR=/path/to/boost_1_88_0 -P
Utilities/Scripts/BoostScanDeps.cmake
```
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
cmake: adapt FindBoost.cmake to our needs
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 <tchaikov@gmail.com>
Since upgrading minimum CMake version to 3.22.1 (commit 469d82a1), we can
now use find_program(REQUIRED) which was introduced in CMake 3.18.
This change replaces manual FATAL_ERROR checks with the REQUIRED option
and adds it to programs that are actually needed during the build. This
ensures the build fails early during configuration rather than later
during compilation when missing programs are invoked.
Changes:
- Replace find_program() + message(FATAL_ERROR) patterns with REQUIRED
- Add REQUIRED to programs that are used during build but previously
had no error checking
Reference: https://cmake.org/cmake/help/latest/command/find_program.html
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
