6

musl チームは、musl libc を検出する方法は必要ないと主張しています。なぜなら、musl libc は標準機能のみを実装しており、検出が必要な癖がないからです。

今日まで、その主張は十分に真実だったかもしれませんが、もはや真実ではありません。機能はあるが壊れているため、通常の機能検出は機能していません。コンパイル時にルートを要求したくないため、クロスコンパイルを許可しないため、プローブしたくありません。バグは最小化されたサンプル コードで報告されており、メンテナーはそれを修正することをまったく望んでおらず、私のパッチも受け取りません。

musl には壊れた機能があるため、他のすべての libc にペナルティを課すつもりはありません。

論理的に言えばやりたい

#if MUSL || APPLE
    pid = fork();
#else
    pid = vfork();
#endif

#if APPLEMac OSXには信頼できないvfork().

vfork()悪いと言われても仕方がない。状況は 2008 年以降変化しておりvfork()、関係する複雑さに関係なく、可能な限りより良い選択です。ソース: https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234

4

2 に答える 2

2

私は非常に遅れていますが、同じ質問に対する答えを見つけようとしているときに、musl libc の 1 つの特異性に気付きました (私の場合、musl は pthread_setname_np を実装していません)。_GNU_SOURCE が定義されている場合、features.h で __USE_GNU を定義せず、代わりに _GNU_SOURCE を使用して GNU 拡張機能を保護します。

したがって、この手順はmusl libcマクロを作成するために機能するはずです（別のlibc実装が同じ動作をするか、何らかの理由でlibcを持たない誰かがスタブfeatures.hを含む場合、誤検知が発生します;しかし、Glibc、uClibc、およびbionicはすべて__USE_GNUを定義しますfeatures.h または features.h に含まれる別のヘッダー (_GNU_SOURCE が定義されている場合)

だからこれは私のために働いていますrn：

#define _GNU_SOURCE
#include <features.h>
#ifndef __USE_GNU
    #define __MUSL__ 
#endif
#undef _GNU_SOURCE /* don't contaminate other includes unnecessarily */
于 2021-12-03T08:08:36.407 に答える