From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: heads-up: Haskell updates Date: Thu, 15 Feb 2018 12:04:04 +0100 Message-ID: <20180215120404.0a96b628@scratchpost.org> References: <87r2ppjbst.fsf@elephly.net> <873723pfya.fsf@netris.org> <871shn8jm5.fsf@elephly.net> <87zi4b744f.fsf@elephly.net> <20180214234721.4e9fe198@scratchpost.org> <87a7waodaa.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emHKp-0006wK-JT for guix-devel@gnu.org; Thu, 15 Feb 2018 06:04:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emHKk-0005UY-Id for guix-devel@gnu.org; Thu, 15 Feb 2018 06:04:15 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:58314) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1emHKk-0005Tc-BB for guix-devel@gnu.org; Thu, 15 Feb 2018 06:04:10 -0500 In-Reply-To: <87a7waodaa.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver , Ricardo Wurmus Cc: guix-devel Hi Mark, Hi Ricardo, On Thu, 15 Feb 2018 03:41:33 -0500 Mark H Weaver 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 detec= ts 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 w= eird 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 >=3D 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 memor= y 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: >=20 > Control/Monad/Trans/Resource/Internal.hs:302:10: error: > =E2=80=A2 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 > =E2=80=A2 In the instance declaration for > =E2=80=98MonadResource (Strict.StateT s m)=E2=80=99 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.