Re: Latest pkgsrc results [What builds on musl 0.9.13?]

[Rich Felker <dalias@aerifal.cx>]

On Sun, Nov 10, 2013 at 06:14:13PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2013-11-09 11:41:47 -0500]:
> > On Sat, Nov 09, 2013 at 05:16:55PM +0100, Szabolcs Nagy wrote:
> > > this is sad
> > > so c++ code that includes mm_malloc.h and stdlib.h will fail
> > 
> > What is mm_malloc.h and why is it declaring malloc itself rather than
> > including stdlib.h?
> > 
> 
> it declares posix_memalign and defined _mm_malloc and _mm_free
> 
> i think it was added to gcc so it is possible to allocate memory
> for the sse intrinsics with the right alignment (included in
> xmmintrin.h which follows the intel and msvc api, see bug report)
> 
> and for c++ they add throw() to posix_memalign so it's incompatible
> with the libc one hence boost fails to build (or anythning that
> uses both xmmintrin.h and stdlib.h)
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16570

I see. Well eseentially, the "linux" mm_malloc.h in gcc is
glibc-specific, then. (BTW, if these prototypes are incompatible, I
think it also means the glibc prototypes are non-conforming to the C++
standard, but that's an entirely separare issue.) I'm not sure what
the proper fix is, though. Would declaring the extern function with
scope local to the _mm_malloc function, rather than file scope, fix
the problem? If so, that could probably be upstreamed in gcc. Another
valid gcc-level fix would be:

extern "C" int __gcc_posix_memalign (void **, size_t, size_t)
    __attribute__((__alias__("posix_memalign"))) throw ();

I'm leaning towards considering this the superior fix, as it also
avoids polluting the namespace with posix_memalign like gcc is
currently doing.

Rich