Already read and understood that.

I agree that adding a "__MUSL__" macro is tricky(or WRONG as said), but 
I think it's will make thing easier.
we can not assume upstream projects will do these checking or will like 
to accept patches to "solve certain implementation" since they assume 
glibc is the standard for now.

It's a comprise, just a suggestion :-)

在 11/17/14 09:26, Ivan Kanakarakis 写道:
> There will never be a __MUSL__ macro.
> Please, see FAQ entry #2 for explanation
> http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
>
>
>
> On 17 November 2014 03:18, 黄建忠 <jianzhong.huang@i-soft.com.cn 
> <mailto:jianzhong.huang@i-soft.com.cn>> wrote:
>
>     Hi, Rich,
>
>     If that means some opensource projects need to be modified to fit
>     Musl,  would you consider to add a "__MUSL__" macro?
>
>     I think such a special macro will make upstream patch easy to be
>     accepted.
>
>
>     在 11/15/14 11:18, Rich Felker 写道:
>
>         Currently musl has MINSIGSTKSZ hard-coded as 2048. This is
>         insufficient to store the ucontext_t for many archs. I'd like
>         to keep
>         it small on archs where that's possible, but the current value
>         might
>         not even work for modern x86 with large AVX state, etc. that
>         needs to
>         be saved. I don't have a proposed fix yet, but I think we should
>         survey the values that are needed for different archs and
>         either make
>         it vary per-arch, or if they're all comparable, just increase the
>         value to something that works for all archs.
>
>         Note that the min pthread stack size is also well below the
>         size of
>         ucontext_t for many archs, but I don't think this is a
>         problem. If you
>         make a thread with a stack smaller than MINSIGSTKSZ+epsilon,
>         you just
>         need to start it with all signals blocked and leave them
>         blocked (or
>         avoid using signal handlers at all).
>
>         Rich
>
>
>
>     -- 
>     Huang JianZhong
>
>
>
>
>
>
> -- 
> /Ivan c00kiemon5ter Kanakarakis/  >:3


-- 
Huang JianZhong