[misc] Kvrocks building problems and solutions on Alpine Linux

[err931]

Search before asking

• I had searched in the issues and found no similar issues.

Motivation

Driven by my intellectual curiosity, I experimented with building Kvrocks on Alpine Linux, which uses musl libc as its C library. During this process, I encountered several build errors, and I would like to share the solutions I discovered with the Kvrocks development team.

Version

• Kvrocks: v2.11.0

Specs

• OS: Alpine Linux 3.21.2
• Compiler: gcc (Alpine 14.2.0)

Error Details

1. Backtrace unavailable.

Since libbacktrace is an extension of glibc and not defined in musl libc, the line find_package(Backtrace REQUIRED) in CMakeLists.txt should be removed. Additionally, the dependency cpptrace suggests using libdwarf for symbol resolution, which should be set as the default option.

2. #include <execinfo.h> unavailable in musl.

This header file is not available in musl libc. Adding a guard as shown below can resolve the issue:

• src/cli/signal_util.h

#ifdef __GLIBC__
#include <execinfo.h>
#endif

3. google/glog v0.7.x causes build errors with musl libc.

This is an issue on the google/glog v0.7.x side, not Kvrocks. We need to wait for bug fixes from the dependent library.

Best regards,

Solution

mentioned above

Are you willing to submit a PR?

• I'm willing to submit a PR!

[aleksraiden]

Thanks about investigation, @err931
Early version of kvrocks use a Alpine (at 2.5.0, see: #1434) but we are switched to debian for compatibility, when fully support of musl are breached.

1 and 2 your points maybe is easy to fix, as I see, but glog is not so easy. Could you add patch for 1 and 2 problems?

[PragmaTwice]

Thank for your effort! It's valuable for Kvrocks.

Since libbacktrace is an extension of glibc and not defined in musl libc, the line find_package(Backtrace REQUIRED) in CMakeLists.txt should be removed.

Yeah it can be removed.

Additionally, the dependency cpptrace suggests using libdwarf for symbol resolution, which should be set as the default option.

IIRC we currently use addr2line as the backtrace backend of cpptrace. For libdwarf it's a little complicated: it's LGPL licensed, and due to ASF policy, it's in Category X. So currently we make it an optional and non-default dep, see here (Note that even we use it, we cannot statically link against it):

kvrocks/cmake/cpptrace.cmake

Lines 27 to 32 in b878275

	if (SYMBOLIZE_BACKEND STREQUAL "libbacktrace")
	set(CPPTRACE_BACKEND_OPTION "CPPTRACE_GET_SYMBOLS_WITH_LIBBACKTRACE=ON")
	elseif (SYMBOLIZE_BACKEND STREQUAL "libdwarf")
	set(CPPTRACE_BACKEND_OPTION "CPPTRACE_GET_SYMBOLS_WITH_LIBDWARF=ON")
	else ()
	set(CPPTRACE_BACKEND_OPTION "CPPTRACE_GET_SYMBOLS_WITH_ADDR2LINE=ON")

Also addr2line is more common, in many distros, than libdwarf.

This header file is not available in musl libc. Adding a guard as shown below can resolve the issue:

If we include it but didn't use it, it can be just removed. Otherwise we should know which function we're using from execinfo.

---

Welcome to open PRs if you like to improve Kvrocks to libc-agnostic.

[err931]

Thanks for your quick reply!

Once I confirm that the build is successful in my development environment, I'll submit a pull request to address these issues.

If we include it but didn't use it, it can be just removed. Otherwise we should know which function we're using from execinfo.

Yeah. I built with the -DSYMBOLIZE_BACKEND=libdwarf option and it was successful. By default (addr2line) had the same result. No problem to delete it. Maybe.