musl 团队声称不需要检测 musl libc 的方法，因为它们只实现标准功能并且没有需要检测的怪癖。
直到今天，这种说法很可能是正确的，但现在已经不再正确了。正常的功能检测不起作用，因为该功能存在但已损坏，我宁愿不探测它，因为我不想在编译时要求 root 并禁止交叉编译。该错误已通过最小化的示例代码报告，维护者根本不想修复它，也不会接受我的补丁。
我不会因为 musl 有一个损坏的功能而惩罚其他所有 libc。
从逻辑上讲我想做
#if MUSL || APPLE
pid = fork();
#else
pid = vfork();
#endif
我已经有的地方#if APPLE因为 Mac OSX 有一个不值得信任的vfork().
没有必要告诉我vfork()不好。 2008年以来，情况发生了变化vfork()无论涉及的复杂性如何，只要有可能，它都是更好的选择。一些来源：https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234 https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234
我很晚了，但在尝试找到同一问题的答案时，我注意到 musl libc 的一个特点（就我而言，是 musl 没有实现 pthread_setname_np）。当定义 _GNU_SOURCE 时，它不会在 features.h 中定义 __USE_GNU，而是使用 _GNU_SOURCE 来保护 GNU 扩展。
因此，这个过程应该可以创建一个 musl libc 宏（如果另一个 libc 实现具有相同的行为，或者没有 libc 的人出于某种原因包含存根 features.h，它将产生误报；但是 Glibc、uClibc 和 bionic 都定义了 __USE_GNU当定义 _GNU_SOURCE 时，在 features.h 或 features.h 包含的其他标头中）
所以这对我有用：
#define _GNU_SOURCE
#include <features.h>
#ifndef __USE_GNU
#define __MUSL__
#endif
#undef _GNU_SOURCE /* don't contaminate other includes unnecessarily */
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
