As seen with openwrt and some other distros, the
determination of hostname can sometime need alternate
commmands.
This provides a cmake option HOSTNAME for non-windows machines
for the mariadb-install-db and mariadbd-safe scripts
and the support-files init scripts..
Use CMake 3.21 (semi)automatic dependency resolution to install server
and plugin dependencies (DLLs).
This is especially useful with 3rd party dependencies, such as Curl, zlib
etc
Update cmake_minimum_required to 2.8...3.12 in root cmake and mroonga.
This will update "Policy Version" to 3.12, which will not prevent the
build by even higher cmake versions. There is also a reason to stay on
the compatible with windows "policy version", so 3.12 is conservatively
chosen.
On the other hand, it will require at least version 2.8.
Prepare for a more modern CMake version than the current minimum.
- Use CMAKE_MSVC_RUNTIME_LIBRARY instead of the custom MSVC_CRT_TYPE.
- Replace CMAKE_{C,CXX}_FLAGS modifications with
add_compile_definitions/options and add_link_options.
The older method already broke with new pcre2.
- Fix clang-cl compilation and ASAN build.
- Avoid modifying CMAKE_C_STANDARD_LIBRARIES/CMAKE_CXX_STANDARD_LIBRARIES,
as this is discouraged by CMake.
- Reduce system checks.
Added a test to verify mariadb-upgrade-service functionality on Windows.
The test runs mariadb-install-db.exe to create a Windows service, then
executes mariadb-upgrade-service.exe while the service is online
or offline.
There is no real cross-version upgrade in this test(not possible with
MTR), the actual goal is just to run smoke-test.
Last times mariadb-upgrade-service was broken (CONC-760, MDEV-30639)
there were problems with named pipe connections, which could be detected
and prevented by smoke-test alone.
When MSAN adds the -fsantize=memory this significantly affects compile
and link tests. Whether this is a compile/run/or looking for a symbol
in a library these cmake tests require the same flags be set.
Ideally the minimum invocation of cmake to create a MSAN build as
investigated in MDBF-793 should be:
-DWITH_MSAN=ON \
-DCMAKE_{EXE,MODULE}_LINKER_FLAGS="-L${MSAN_LIBDIR} -Wl,-rpath=${MSAN_LIBDIR}"
On the assumption that the compiler supports msan and the instrumented
libraries are in MSAN_LIBDIR (maybe later can be made a cmake option).
Without cmake policy below, the checking of everything from libc++ to
libfmt will not have the supplied linker flags or the compile options
that WITH_MSAN=ON invokes. Many try_compile and CMake functions that
wrapped this and headers failed to be recognised due to missing msan symbols
when linking. Also without the -L path, they where applying a link test
to the default path libraries rather than the MSAN instrumented ones.
The CMake policy enabled is CMP0056, added CMake 3.2, applies
CMAKE_EXE_LINKER_FLAGS to try_compile.
With this change the MY_CHECK_AND_SET_COMPILER_FLAG
remove explict build types resulting in just CMAKE_{C,CXX}_FLAGS being
set rather than CMAKE_{C,CXX}_FLAGS_{DEBUG,RELWITHDEBINFO}. These
are needed for the default CMP0066 policy to be correctly applied and
the msan flags of -fsanitizer=memory are applied to all compile checks.
Likewise with MY_CHECK_AND_SET_LINKER_FLAG for CMAKE_{EXE,MODULE,SHARED}_LINKER_FLAGS
for those check that involve full linking and CHECK_CXX_SOURCE_RUNS for
example.
This commit adds the capability to generate a Software Bill of Materials
(SBOM) from server builds.
It introduces a new WITH_SBOM variable, which defaults to ON for package
builds (i.e if BUILD_CONFIG is used) and to OFF otherwise.
When enabled, the build process will produce an sbom.json document in
CycloneDX format, capturing information about various dependencies,
which is gathered from various sources.
We use git submodule information and CMake external projects properties
to gather version information for 3rd party code, but also handle
dependencies if external code is part of our repository
(zlib, or Connect storage engine's minizip)
The SBOM document is stored in the root build directory in sbom.json file,
but is not currently installed.
Libmariadb introduced a cmake change that required 3.12 or newer.
Since none of the platforms we currently support have anything lower
than 3.12 available, we should make this a proper requirement for the
Server as well.
All the options that where in buildbot, should
be in the server making it accessible to all
without any special invocation.
If WITH_MSAN=ON, we want to make sure that the
compiler options are supported and it will result
in an error if not supported.
We make the -WITH_MSAN=ON append -stdlib=libc++
to the CXX_FLAGS if supported.
With SECURITY_HARDENING options the bootstrap
currently crashes, so for now, we disable SECRUITY_HARDENING
if there is MSAN enable.
Option WITH_DBUG_TRACE has no effect in MSAN builds.
The final touch to fixing memory leaks for PS/SP. This patch turns on
by default the option WITH_PROTECT_STATEMENT_MEMROOT in order to
build server with memory leaks detection mechanism switched on.
Starting with GCC 10, let us enable _GLIBCXX_DEBUG as well as
_GLIBCXX_ASSERTIONS which have an impact on the GNU libstdc++.
On GCC 8, we observed a compilation failure related to some
missing type conversion.
Even though clang on GNU/Linux would default to using libstdc++
and enabling the debugging seems to work with clang-18, we will
not enable this on clang, in case it would lead to compilation
errors.
For the clang libc++ before clang-15 there was _LIBCPP_DEBUG,
but according to
llvm/llvm-project@f3966eaf86 and
llvm/llvm-project@13ea134323 and
llvm/llvm-project@ff573a42cd it
looks like that for proper results, a specially built debug version
of libc++ would have to be used in order to enable equivalent checks.
This should help catch bugs like the one that
commit 455a15fd06b0f449e72e6b10b0474e4139eeeca2 fixed.
Reviewed by: Sergei Golubchik
