Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1
*From:* Austin Seipp mailto:aus...@well-typed.com *Sent:* Tuesday, December 23, 2014 15:36 *To:* ghc-devs@haskell.org mailto:ghc-devs@haskell.org, glasgow-haskell-us...@haskell.org mailto:glasgow-haskell-us...@haskell.org We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ Besides downloading a tarball, can I checkout it using git? I tried using sync-all as described on wiki [1] to checkout it: ./sync-all checkout ghc-7.10 but it seems it doesn't work, there are error message like: error: pathspec 'ghc-7.10' did not match any file(s) known to git. [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Build on Windows fails
On 10/17/2014 6:36 PM, David Macek wrote: Hi all. My build fails, log: https://gist.github.com/elieux/2b2a074e03005f7754d6 I'm working on Windows x64, using msys2 with mingw64-x86_64 4.9.1. What I did: [...] download http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-src.tar.xz I had trouble building 7.8.3 under msys2 myself before, but it is okay to build ghc trunk. If you don't have to stick to a specific version, I would suggest you try trunk -- it is 7.9.2 at the moment. -- cg ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Curious Windows GHCi linker behaviour .o vs. .dll
On 10/11/2014 9:24 PM, Herbert Valerio Riedel wrote: Consider the following trivial program: module Main where foreign import ccall unsafe time.h tzset c_tzset :: IO () main :: IO() main = c_tzset [...] However, when loaded into GHCi, the RTS linker fails to find `tzset`: $ ghci tz.hs [...] ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: tzset Strange, I tried it under HaskellPlatform-2014.2, it works, I didn't see the failure. And I tried it in both Windows cmd and msys2 shell. However, when I prefix a `_` to the symbol-name in the FFI import, i.e. foreign import ccall unsafe time.h tzset c_tzset :: IO () I guess it should read: foreign import ccall unsafe time.h _tzset c_tzset :: IO () It works too. Actually both _tzset and tzset exist in include/time.h, only tzset is old style name. They will be linked as the same function __imp__tzset. -- cg ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Curious Windows GHCi linker behaviour .o vs. .dll
On 10/11/2014 11:44 PM, Herbert Valerio Riedel wrote: Well, I basically used a MSYS2 environment setup according to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows I reproduced the issue with ghc-7.8.3-x86_64. Are you using 64-bit ghc? If so, it looks the issue is 64-bit only. Actually both _tzset and tzset exist in include/time.h, only tzset is old style name. They will be linked as the same function __imp__tzset. What do you mean by old style? And more importantly, what foreign-import line shall be used that works both on Windows and non-Windows platforms, compiled as well as interpreted in GHCi? I meant OLDNAME in MS's jargon, because they deprecate tzset [1], then call it 'old'. But it it still usable. [1] http://msdn.microsoft.com/en-us/library/ms235451.aspx -- cg ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Broken build: 32-bit FreeBSD, SmartOS, Solaris
On 10/10/2014 9:40 PM, Páli Gábor János wrote: 2014-10-10 13:30 GMT+02:00 cg chengan...@gmail.com: How can I configure to build x86_64? When I build GHC (with msys2), it always builds i386 and I haven't spotted the option in ./configure to choose a x86_64 release. This is implicitly determined by the toolchain you use. So, probably you have the i686 msys2 installed, while you would need the x86_64 version. Given, that your operating system (and thus your hardware) is also x86_64. It turns out if I have 64-bit prebuilt ghc installed and exported in PATH, the build system will detect it and build a 64-bit ghc from source code. -- cg ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building ghc on Windows with msys2
On 10/1/2014 6:25 AM, Simon Peyton Jones wrote: ·[...] The important thing is that it should be reproducible, and not dependent on the particular Cygwin or gcc or whatever the that user happens to have installed. Exactly. So how about setting up a build server using msys2? I guess the current two build server are all Cygwin based, they are failing at the same permission issue at early building stage, it prevents checking out the real problem. It seems msys2 (or msys) seldom has such issue. Best Regards cg ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building ghc on Windows with msys2
On 10/8/2014 1:03 AM, Austin Seipp wrote: I hide 'empty' and 'foldr' at importing point and the code compiles. Has anyone see the same issues? Ugh, this is some fallout I thought we had fixed, but apparently not. I'll fix it shortly, thanks. [...] Why does ghc-stage1.exe use so much memory? Wow, I thought we fixed this one too! Please see this bug: https://ghc.haskell.org/trac/ghc/ticket/9630 What GHC commit are you using? Are your submodules all up to date? In particular, if 'binary' is not up to date, even if the rest of your tree is, you'll see this problem. Ah, I know what causes the building failure now... After cloning ghc repository, I switch every sub-module to Master (it is usually HEAD) branch. I am in the habit of thinking Master is always the latest. But it is not the case with ghc. For example, the fix mentioned in ticket 9630 was submitted to ghc-head branch[1], but the Master/HEAD is way old[2]. And it seems there is some other submodule is like this. Now after cloning ghc repository, if I don't switch to any branch -- 'git branch' will show all submodules are detached -- the build will succeed. So why the Master/HEAD branches don't have the latest code? Thanks, cg [1] http://git.haskell.org/packages/binary.git/log/refs/heads/ghc-head [2] http://git.haskell.org/packages/binary.git/log/refs/heads/master ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
