Use capi for syscalls that break under musl's handling of 64-bit time_t

[redneb]

I maintain a repo with builds of GHC for the musl C standard library and I encountered a subtle bug of this library that affects GHC under 32-bit architectures with musl.

In 32-bit architectures, there was a transition where the C type time_t was redefined to be 64-bit in order to address the Y2038 problem. The way this was handled by musl was by introducing new versions of all affected syscalls that work with 64-bit time_t (e.g. __clock_gettime64 is like clock_gettime but with 64-bit time_t). In addition, a redirect was introduced to create an alias of the new versions of these functions under the old name (e.g. here's the redirection for clock_gettime).

The problem is that this redirection is defined as a C macro in a C header file and as such, it does not get picked by GHC when the foreign function import is done via ccall, but works just fine when capi is used. So this PR changes all affected syscalls to be imported with capi, which should be a fairly uncontroversial change.

[AshleyYakeley]

You'll have to fix the builds. (There's a recent fix in master for the Free BSD build, so that might work here.)

[redneb]

I fixed the CI builds: there was a wrong header used for gettimeofday. There correct header for it is sys/time.h but time.h was being used. With ccall this didn't cause failures but capi is less forgiving.

[AshleyYakeley]

Looks good. Is there any easy way of testing this? Ideally it would be great to have a CI build for musl, to ensure that it didn't get broken in the future.

[redneb]

I am working to create some musl based docker images, but for now I am not sure if there is an easy way. BTW this breakage was for 32 bit architectures only.

[AshleyYakeley]

OK, well if you come up with something feel free to make a PR for a CI build later on.