[Nix-dev] GHC "unable to decommit memory"

[Shea Levy]

It is common practice when developing against relatively recent features
to handle ENOSYS/EINVAL/etc. in *application* code. It's completely
proper that the library exports it anyway.

Kevin Cox <kevincox at kevincox.ca> writes:

> On Sep 1, 2016 10:03, "Eelco Dolstra" <eelco.dolstra at logicblox.com> wrote:
>>
>> Hi,
>>
>> On 09/01/2016 10:09 AM, Kevin Cox wrote:
>>
>> > Sounds more like we need glibc to support the kernel we are using. GHC
> is
>> > behaving fine and probably not the only program to have this problem.
>>
>> Glibc supports our kernel just fine - it just makes available some
> features that
>> our kernel doesn't have, which is not uncommon. I mean, what should Glibc
> do in
>> this case? The fix would be to build GHC with
> --disable-large-address-space or
>> apply patch https://ghc.haskell.org/trac/ghc/ticket/12495.
>>
>
> It doesn't sound just fine if it is advertising features that don't exist.
> Is there a way to prevent glibc from saying that MADV_FREE is supported? I
> understand that glibc "supports" it but it probably shouldn't be advertised
> if the kernel underneath doesn't.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160901/0a94686f/attachment.sig>