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 <[email protected]> writes: > On Sep 1, 2016 10:03, "Eelco Dolstra" <[email protected]> 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 > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev
signature.asc
Description: PGP signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
