Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
> http://koji.fedoraproject.org/koji/getfile?taskID=3251249&name=build.log > . >>> | *** unexpected failure for fed001(normal) > Note the Fedora build is patched to use system libffi. >>> Hmm. What happens if you don't patch it? >> More hmmm: that makes the x86 unexpected errors go to 0! >> http://koji.fedoraproject.org/koji/taskinfo?taskID=3253482 > This is surprising because I don't think ordinary FFI code should be even > using libffi on x86 - we have our own implementation in rts/Adjustors.c. In > 7.2 there are some changes in this area because we now guarantee to keep the > C stack pointer aligned on a 16-byte boundary (see > http://hackage.haskell.org/trac/ghc/ticket/5250), and as a result we > switched to using the Mac OS X implementation in rts/Adjustors.c which was > already doing the necessary alignment. I see, thanks for the explanation. :) > You aren't setting UseLibFFIForAdjustors=YES anywhere, are you? (even if you > were, I would expect it to still work though, albeit a bit more slowly). No, I don't think so. The Fedora ghc build is pretty standard - it should be very close to the upstream defaults. >> It would be good to make Linux default to use system libffi anyway. : > I don't like having to do this, but it reduces our testing surface (we don't > want to have to test against N different versions of libffi). Ok, but recently libffi is not updated that often. (Fedora will have shipped 3.0.9 for 4 releases soon (and the previous 4 releases were with 3.0.5). I suspect other distros are similar.) > I'm quite happy for distros to build against their system libffi though, and > we should > make that easier. Note that if you build against the system libffi you are > responsible for fully testing the combination (I know you already do that, > which is great). A configure option to enable system libffi would be very good. Should I file an RFE for that? Thanks, Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
>> Should I try to send a patch for the remove all backward compatibility >> thing? Or one for the specific #include problem I've been having? > > I've lost track of all the details here. But perhaps there's some > historical cruft lying around because hsc2hs used to call GHC to compile its > C files, and hence __GLASGOW_HASKELL__ would have been defined. Ahh, that could be the explanation. Perhaps it's been continued just because someone was making incremental updates and never realized the original reason the macro worked. > In fact, the GHC build system passes --cflag=-D__GLASGOW_HASKELL__= > to hsc2hs when it runs it. Maybe Cabal should do the same. Does it? I don't know, but I'm not using cabal. > The problem with making the INCLUDE pragma conditional is that you can only > do conditional pragmas using CPP, which requires the CPP extension, and > moreover older versions of GHC did not support conditional compilation of > pragmas (I forget which version added this, maybe 6.12). Right, but unless I'm mistaken, the CPP never goes into haskell, it goes into the generated C. So the simplest thing to do is remove all the version stuff. That means that if you want to run hsc2hs with a version of ghc which is not the one linked in /usr/bin, you also can't run the hsc2hs linked in /usr/bin, but have to get the one out of the ghc directory. If no one has an objection to that then I'll try to make a patch with git and put it in a ticket. The next simplest thing to do is to just document that anyone calling hsc2hs has to pass -D__GLASGOW_HASKELL_=version. I don't like this so much because it's error-prone, but doesn't require any code changes. So... remove it all? Yea / nay? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
Ian Lynagh: > On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote: >> Ian Lynagh: >> You are right that the bindists use the default gcc (i.e., the one with the >> LLVM backend). That is ok, though, as GHC supplies the stack unwinding >> linker option. > > Do you really mean the bindists (i.e. the .tar.bz2 files), rather than > the installers (.pkg)? Yes, I mean the tar.bz2 file. When I unpack it on Lion and run ./configure, configure picks '/usr/bin/gcc' and not '/usr/bin/gcc-4.2' as the C compiler. (I can force it to use gcc-4.2 with '--with-gcc=/usr/bin/gcc-4.2'.) Manuel P.S.: The .pkg package uses a bindist internally. (At least, that was how my original implementation of the packaging worked.) So, the two should usually behave the same. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On 07/08/2011 02:18, Evan Laforge wrote: On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynagh wrote: But I also think we may as well just remove most of these conditionals. The GHC< 4.09 tests can surely be removed, and likewise the GHC< 6.3 tests. Personally I'd remove the GHC< 6.10 test too, but perhaps that will be more contentious. Any opinions? That was going to be my first suggestion. Maybe the only reason these are needed is that the hsc2hs binary itself isn't versioned, otherwise you simply run the one that came with your ghc, and if it's for ghc-4 then it should be producing code ghc-4 understands. So the problem would be with code that knows to specifically invoke an older ghc, but still picks up the hsc2hs symlink which points to a newer one. I don't know of any framework for compiling with multiple versions, but I'd think it should be smart enough to find the appropriate ghc lib directory and run the various utilities out of there. So what's the consensus here? Does dropping all backwards compatibility from hsc2hs make sense? Presumably it's there for a reason so I may be missing something. In any case, though I like the idea of dropping all the #ifdef, I think the specific instance for omitting #includes is incorrect, and I'm not sure why other people aren't seeing that.. I don't understand what's going on with __GLASGOW_HASKELL__. Maybe something funny with my install? Should I try to send a patch for the remove all backward compatibility thing? Or one for the specific #include problem I've been having? I've lost track of all the details here. But perhaps there's some historical cruft lying around because hsc2hs used to call GHC to compile its C files, and hence __GLASGOW_HASKELL__ would have been defined. In fact, the GHC build system passes --cflag=-D__GLASGOW_HASKELL__= to hsc2hs when it runs it. Maybe Cabal should do the same. Does it? The problem with making the INCLUDE pragma conditional is that you can only do conditional pragmas using CPP, which requires the CPP extension, and moreover older versions of GHC did not support conditional compilation of pragmas (I forget which version added this, maybe 6.12). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote: > Ian Lynagh: > > On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote: > >> > >> The RC unfortunately doesn't build on Lion (OS X 10.7). > > > > I've put the latest 7.2 source here, along with OS X builds: > >http://www.haskell.org/ghc/dist/7.2.1-rc2/ > > > > My guess is that the bindists will work on Lion, but that the installers > > will use the wrong gcc. > > I tested the 64-bit bindists and compiled the source from scratch on Lion. > It all works. Great, thanks! > You are right that the bindists use the default gcc (i.e., the one with the > LLVM backend). That is ok, though, as GHC supplies the stack unwinding > linker option. Do you really mean the bindists (i.e. the .tar.bz2 files), rather than the installers (.pkg)? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
Ian Lynagh: > On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote: >> >> The RC unfortunately doesn't build on Lion (OS X 10.7). > > I've put the latest 7.2 source here, along with OS X builds: >http://www.haskell.org/ghc/dist/7.2.1-rc2/ > > My guess is that the bindists will work on Lion, but that the installers > will use the wrong gcc. I tested the 64-bit bindists and compiled the source from scratch on Lion. It all works. You are right that the bindists use the default gcc (i.e., the one with the LLVM backend). That is ok, though, as GHC supplies the stack unwinding linker option. When compiling the source, the build system picks gcc-4.2 (as it should, otherwise the RTS wouldn't compile). I still think that the bindists should use gcc-4.2 as well. However, that's nothing that should hold up the 7.2.1 release. Cheers, Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
