initial resolute raccoon support

[mkocher]

Feature or Bug Description

These changes enable compiling pxc-release on Resolute Raccoon, the new Ubuntu LTS version. These changes were made during the production of the initial alpha stemcell to validate that cf-deployment can be deployed using the new stemcell.

Related Issue

cloudfoundry/bosh-linux-stemcell-builder#497
uutils/coreutils#11469

AI Slop Explanation of Changes

Overview

Resolute Raccoon ships with significantly newer toolchains than Jammy (22.04):

Tool	Jammy	Resolute
GCC	12	14/15
CMake	3.22	4.2
Default C standard	C17	C23
pkg-config	pkg-config 0.29	removed (pkgconf only)

These upgrades break compilation of several vendored packages. All changes
below are backward-compatible with Jammy unless otherwise noted.

---

Changed packages

1. pkg-config replaced by pkgconf (all packages that need it)

Affected packages: percona-xtrabackup-8.0, percona-xtrabackup-8.4,
percona-xtradb-cluster-8.0, percona-xtradb-cluster-8.4

Problem: Resolute Raccoon no longer ships the classic pkg-config binary.
The pkgconf project is its replacement but is a distinct upstream project,
not a rename.

Fix: Each affected package now vendors and builds pkgconf from source,
then creates a pkg-config symlink so existing build scripts continue to work:

tar -xf pkgconf/pkgconf-*.tar.gz
cd pkgconf-pkgconf-*/
./autogen.sh
./configure --prefix=/usr
make -j "$(nproc)" install
ln -sf pkgconf /usr/bin/pkg-config
cd -

The blob pkg-config_0.29.2.orig.tar.gz was removed and replaced with
pkgconf/pkgconf-2.5.1.tar.gz. The spec files were updated accordingly.

Jammy compat: Works fine. pkgconf is a drop-in replacement.

---

2. socat bumped from 1.7.4.4 to 1.8.1.1

Affected packages: percona-xtradb-cluster-8.0, percona-xtradb-cluster-8.4

Problem: The vendored socat 1.7.4.4 uses const-incorrect casts of
strchr() return values and other patterns that GCC 14+ treats as hard errors
under the default C23 standard (specifically -Werror=incompatible-pointer-types).

Fix: Bumped the socat blob to 1.8.1.1 which has upstream fixes for modern
compiler compatibility.

Jammy compat: socat 1.8.x works on Jammy. No behavioral changes.

---

3. percona-xtrabackup-2.4 — CMake 4.2 and GCC 14 fixes

Problem: PXB 2.4 is very old code with multiple incompatibilities:

1. Removed CMake policies (CMP0018, CMP0022, CMP0042, CMP0045): CMake 4.2
   removed support for setting these policies to OLD. The source
   CMakeLists.txt had explicit cmake_policy(SET CMPxxxx OLD) calls.

2. GET_TARGET_PROPERTY on non-existent targets: CMake 4.2 now errors
   when calling GET_TARGET_PROPERTY() on a target that doesn't exist.
   This happened in cmake/libutils.cmake for system libraries.

3. INSTALL_DEBUG_TARGET on non-existent targets: The
   INSTALL_DEBUG_TARGET(mysqld) macro call fails because mysqld is not
   built in xtrabackup mode.

4. sig_return typedef: include/my_global.h defines
   typedef void (*sig_return)(); — the empty parens mean (void) in C23,
   conflicting with signal handler signatures that take int. GCC 14 treats
   this as a hard error.

Fix:

• sed in packaging to strip the obsolete CMake policy lines:

  sed -i '/CMAKE_POLICY.*SET.*CMP00\(18\|22\|42\|45\).*OLD/d' CMakeLists.txt

• sed in packaging to fix the sig_return typedef:

  sed -i 's/sig_return)();/sig_return)(int);/' include/my_global.h

• A patch -p1 with src/percona-xtrabackup-2.4-patches/cmake42-compat.patch
  that guards GET_TARGET_PROPERTY calls and the INSTALL_DEBUG_TARGET macro
  with IF(TARGET ...) checks.

• Added -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to the cmake invocation.

Jammy compat: All changes are safe on Jammy. The sed commands are
no-ops if the patterns don't match, and the patch applies cleanly regardless
of CMake version.

---

4. percona-xtrabackup-8.0 — OpenSSL discovery and pkgconf

Problem: CMake's FindOpenSSL couldn't locate libcrypto.so and
libssl.so on Resolute because the library directory moved. The package
also needed pkgconf (see item 1).

Fix: Added explicit library paths via pkg-config:

ssl_lib_dir=$(pkg-config --variable=libdir openssl 2>/dev/null || echo /usr/lib/x86_64-linux-gnu)

Then passed to cmake:

-DOPENSSL_CRYPTO_LIBRARY="${ssl_lib_dir}/libcrypto.so"
-DOPENSSL_SSL_LIBRARY="${ssl_lib_dir}/libssl.so"

Jammy compat: The fallback || echo /usr/lib/x86_64-linux-gnu ensures
Jammy still works even if pkg-config isn't available.

---

5. percona-xtradb-cluster-8.0 and 8.4 — multiple fixes

These two packages required the most work. Three distinct problems:

5a. Bundled libtirpc — K&R function declarations vs C23

Problem: PXC bundles libtirpc as an ExternalProject. The libtirpc
source uses K&R-style function declarations with empty parentheses, e.g.:

void svcauth_none_destroy()  /* K&R: means unspecified args */

In C23 (GCC 14's default), empty parens mean (void), which conflicts with
the actual prototype void svcauth_none_destroy(AUTH_STAT *, ...). This
produces conflicting types errors.

Fix: Inject -std=gnu17 into the tirpc sub-build's C flags. The sed
targets the ExternalProject's CMakeLists.txt to force C17 mode:

sed -i '/^SET(TIRPC_C_FLAGS/a STRING_APPEND(TIRPC_C_FLAGS " -std=gnu17")' ../extra/tirpc/CMakeLists.txt

Note the ../ prefix — this runs from the bld/ subdirectory.

Why not -DWITH_TIRPC=system? The Resolute stemcell doesn't include
libtirpc-dev headers, so we must use the bundled copy.

Jammy compat: The sed is harmless on Jammy. GCC 12 already uses C17 by
default, so the explicit flag is redundant but not harmful.

5b. Boost discovery for the Galera sub-project

Problem: The Galera sub-project (which builds garbd, the Galera
arbitrator daemon) calls find_package(Boost COMPONENTS program_options).
CMake 4.2 changed its config-mode search behavior, causing Boost discovery
to fail even though BOOST_ROOT is set.

Fix (two parts):

1. Build Boost program_options and system libraries (already done in
   install_build_dependencies):

   ./bootstrap.sh --with-libraries=program_options,system
   ./b2 -j "$(nproc)" link=static

2. Generate BoostConfig.cmake and BoostConfigVersion.cmake at runtime
   in the Boost directory. These files tell CMake where the headers and
   compiled libraries are, and define proper imported targets:

   add_library(Boost::program_options STATIC IMPORTED)
   set_target_properties(Boost::program_options PROPERTIES
     IMPORTED_LOCATION ".../stage/lib/libboost_program_options.a"
     INTERFACE_INCLUDE_DIRECTORIES "...")

Without the imported targets, CMake finds the headers but the linker fails
with undefined reference to boost::program_options::* when linking garbd.

Jammy compat: The generated CMake config files are always written and
always used. They point to the locally-built Boost, which works on any platform.

5c. OpenSSL library discovery (8.0 only)

Same fix as PXB 8.0 (item 4) — explicit OPENSSL_CRYPTO_LIBRARY and
OPENSSL_SSL_LIBRARY flags.

PXC 8.4 did not need this fix — its CMake handles OpenSSL discovery
correctly on its own.

Notes on build time

PXC 8.0 and 8.4 are enormous builds (~70-80 minutes each on the BOSH
compilation VM). When both compile in parallel on the same VM, the combined
memory pressure can cause GCC to segfault (ICE: "internal compiler error:
Segmentation fault signal terminated program cc1plus"). This is transient —
a redeploy succeeds because one package is already cached, leaving full
resources for the other. If you see this in CI, a retry is the fix.

Things to watch for in the future

• PXB 2.4 is end-of-life. The source is not maintained for modern
  toolchains. Every future compiler or CMake bump will likely require new
  patches. Consider dropping PXB 2.4 support if possible.

• Boost version. Both PXC 8.0 and 8.4 pin to Boost 1.77.0. If a future
  PXC version bumps Boost, the version strings in the generated
  BoostConfig.cmake / BoostConfigVersion.cmake must be updated to match.

• libtirpc C standard. The -std=gnu17 workaround forces the bundled
  libtirpc to compile in C17 mode. If a future PXC version updates its
  bundled libtirpc to one that has proper C23-compatible prototypes, this
  sed can be removed.

• socat version. We bumped to 1.8.1.1. Future PXC versions may vendor
  a different socat; check that it compiles with the stemcell's GCC.

---

[abg]

PXB 2.4 is end-of-life. The source is not maintained for modern
toolchains. Every future compiler or CMake bump will likely require new
patches. Consider dropping PXB 2.4 support if possible.

This is probably worth considering separately. PXB v2.4 was preserved since PXC v8.0 (still supported) depends on it and any node provisioning operations fail if this executable is not found.

We could potentially put a "placeholder" script or patch the PXC v8.0 wsrep_sst_xtrabackup-v2 script. I do not really like patching the wsrep sst script because it is such a mess of bash already and impacts supportability.

Probably worth a discussion for Percona as this removes another EOL dependency from the release (which is, somewhat strangely, depended on by a still-supported PXC v8.0 dependency).

[abg]

Any reason why libicu-dev was dropped from ubuntu-resolute so we have to do this?

It was on noble (and jammy)

[abg]

I don't think we need this? At least I did not run into an issue manually running cmake && make install under ubuntu-resolute.

CMake Warning:
  Manually-specified variables were not used by the project:

    Boost_NO_BOOST_CMAKE

[abg]

I don't think we need these OPENSSL_* hints either.

At least, I was able to compile by hand under ubuntu-resolute without these - but I did need the new pkgconf.