hmatrix doesn't build against musl libc

[nh2]

For the advancement of static linking in Haskell (https://github.com/nh2/static-haskell-nix and https://github.com/NixOS/nixpkgs/issues/43795) I'm building all Stackage executables statically, which means building against musl libc instead of glibc.

hmatrix doesn't compile against musl.

The biggest issue seems to be the use of the random_rI() function with is a glibc extension.

I get:

src/Internal/C/vector-aux.c:1066:5: error:
     warning: implicit declaration of function ‘random_r’; did you mean ‘random’? [-Wimplicit-function-declaration]
         random_r(buffer,&res);
         ^~~~~~~~

The code already handles absence of random_r on some platforms:

https://github.com/haskell-numerics/hmatrix/blob/94c7f89929e09ca6e98976cb59dec574ee164e20/packages/base/src/Internal/C/vector-aux.c#L935-L942

But the way the decision is done is not good: defined (__APPLE__) || (__FreeBSD__).

Instead it should better use the feature test macros as described in the man page, which are specifically designed for this task:

       random_r(), srandom_r(), initstate_r(), setstate_r():
           /* Glibc since 2.19: */ _DEFAULT_SOURCE
               || /* Glibc versions <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE

So you should be able to check for the presence of random_r() by checking

/* Glibc since 2.19: */ _DEFAULT_SOURCE || /* Glibc versions <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE

in your #if. That evaluating to 1 means that random_r() is available, otherwise it may not be available.

I would very much appreciate if you can help me with this as static linking will make numerical Haskell programs much easier to deploy and run in a distributed fashion.

---

I have researched 30 minutes into whether there's a significantly better alternative function to use in musl vs what you do on FreeBSD but haven't found anything real yet.

So it would probably be sufficient for now if musl went down the FreeBSD/OSX code path.

This article may be interesting:

• http://www.evanjones.ca/random-thread-safe.html

[idontgetoutmuch]

@nh2 very happy to help but it will take me some time to investigate this

[idontgetoutmuch]

Is this still a problem for you?

[nh2]

Yes

[nh2]

I've PR'd #301 as a workaround, so that the relevant code can at least be turned off manually.