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



On 17 November 2014 03:18, 黄建忠 <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