我们应当在工程编译根文件之中,定义一个 MUSL 编译器分支宏来决定本次编译是否为利用 MUSL-LIBC CRT运行时编译的工程程式。
因为在通过 MUSL 编译时,我们存在一些函数上的使用限制,比如;64位扩展函数不能用,如:lseek64。
如果要展开 lseek64 函数的编译使用,我们需要打开工程预编译器宏:_LARGEFILE64_SOURCE
该宏在 GUN/LLVM C++ 之中使用 GLIBC 运行库CRT时,是默认被定义的,但在 MUSL 之中缺省是没有定义的。
CMakeLists.txt 预编译器宏定义:
cpp
# When compiling with the musl-libc standard library,
# You need to define the _MUSL__ preprocessor macro to ensure correct compilation.
# https://wiki.musl-libc.org/faq
# ADD_DEFINITIONS(-D__MUSL__)
# When using the musl-libc standard library, the _LARGEFILE64_SOURCE macro is not defined by default on some platforms.
# If 64-bit functions extended by _LARGEFILE64_SOURCE, such as lseek64, are required, it needs to be explicitly defined.
# ADD_DEFINITIONS(-D_LARGEFILE64_SOURCE)
另外在 MUSL 之中,我们需要频闭对于 GUN/C/C++ 扩展函数库:#include <execinfo.h> 的使用,所以不要指望,可以通过该函数解释C符号。
backtrace、backtrace_symbols、abi::__cxa_demangle 这些函数都是无法使用的。
但是人们仍旧期望,可以堆栈回溯,可以使用高版本 boost 实现的 stacktrace 类,boost 对于 MUSL 环境的堆栈捕获,已经做了编译自适应兼容性。
cpp
boost::stacktrace::stacktrace st;
return boost::stacktrace::to_string(st);
所以,我很讨厌某些装逼人,技术不咋地,这个瞧不起、那个瞧不起,boost 库那么好用,兼容性这块没得说,除了代码量确重了点,然而并不差,但这个可以花点时间剔一下不用的代码的。
另外在 MUSL 之中,我们不能引入以下两个头文件:
这是GUN/LINUX特有的。
cpp
#include <error.h>
#include <sys/poll.h>
#include <sys/poll.h> 是UNIX特有的。
在 MUSL 之中,我们需要这么引入这两个头文件,人们需要注意一下。
cpp
#if defined(__MUSL__)
#include <err.h>
#include <poll.h>
#else
#if defined(_MACOS)
#include <errno.h>
#include <sys/poll.h>
#elif defined(_LINUX)
#include <error.h>
#include <sys/poll.h>
#endif
#endif
。