Re: heads-up: Haskell updates

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Mark,
Hi Ricardo,

On Thu, 15 Feb 2018 03:41:33 -0500
Mark H Weaver <mhw@netris.org> wrote:

> Given that it's using #ifdef to detect this, I'd expect the result to
> depend only on the _headers_ being used to compile, and not the actual
> kernel running the build.

Yes, that's precisely the problem.

* The [glibc or kernel] headers determine whether the ghc compilation detects it
* The Linux kernel determines whether the functionality is actually present at
runtime when any ghc program (like ghc-pkg) runs.

Linus takes backward compatibility seriously - the constants
or functionality are not going to vanish from Linux later.

So the only problematic case is that the build process finds MADV_FREE
but the running Linux doesn't yet have it and a ghc program runs on it.

Reading MADV_DONTNEED docs again, MADV_DONTNEED pretty much does the same
as MADV_FREE - but MADV_DONTNEED promises to make later accesses to the
range succeed (by providing a new zero-filled page if necessary) while
MADV_FREE promises to make them fail.

So one could fall back to MADV_DONTNEED - should be fine, though a little weird
for an allocator.

If that's the case and the build still fails, let's just apply the Haskell patch
to ghc (or update ghc if there's a newer release).

> why it works for Ricardo but not for Andreas and Hydra.

At runtime it depends on the Linux kernel version present whether
the deallocation will work or not.

So I suspect that Ricardo has a Linux >= 4.5 but Andreas and Hydra
have a Linux < 4.5.  Is that correct?

Ricardo, you said you built on master - but in master's glibc the situation
is the same:

~/x/glibc-2.25$ grep -r MADV_FREE bits
./bits/mman-linux.h:# define MADV_FREE    8     /* Free pages only if memory pressure.  */

Still would fail for Linux < 4.5.

> Note that on our 'master' branch we are using Linux-libre-4.4 kernel
> headers, but on 'core-updates' we're using 4.9 kernel headers.
[...]
> I suppose if one reads the error message literally:
> 
>   Control/Monad/Trans/Resource/Internal.hs:302:10: error:
>       • Could not deduce (MonadBase IO (Strict.StateT s m))
>           arising from the superclasses of an instance declaration
>         from the context: MonadResource m
>           bound by the instance declaration
>           at Control/Monad/Trans/Resource/Internal.hs:302:10-63
>       • In the instance declaration for
>           ‘MonadResource (Strict.StateT s m)’

I think it just didn't update one of the packages or the package database
and now it got the wrong version where someone changed the type signature
on one side and the other side is stale.