GUN C/C++ 关于利用 musl-libc 编译兼容性

我们应当在工程编译根文件之中，定义一个 __MUSL__ 编译器分支宏来决定本次编译是否为利用 MUSL-LIBC CRT运行时编译的工程程式。

因为在通过 __MUSL__ 编译时，我们存在一些函数上的使用限制，比如；64位扩展函数不能用，如：lseek64。

如果要展开 lseek64 函数的编译使用，我们需要打开工程预编译器宏：_LARGEFILE64_SOURCE

该宏在 GUN/LLVM C++ 之中使用 GLIBC 运行库CRT时，是默认被定义的，但在 __MUSL__ 之中缺省是没有定义的。

CMakeLists.txt 预编译器宏定义：

# 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__ 环境的堆栈捕获，已经做了编译自适应兼容性。

        boost::stacktrace::stacktrace st;return boost::stacktrace::to_string(st);

所以，我很讨厌某些装逼人，技术不咋地，这个瞧不起、那个瞧不起，boost 库那么好用，兼容性这块没得说，除了代码量确重了点，然而并不差，但这个可以花点时间剔一下不用的代码的。

另外在 __MUSL__ 之中，我们不能引入以下两个头文件：

这是GUN/LINUX特有的。

#include <error.h>
#include <sys/poll.h>

#include <sys/poll.h> 是UNIX特有的。

在 __MUSL__ 之中，我们需要这么引入这两个头文件，人们需要注意一下。

#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

。