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

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.

On 02/08/2011 13:52, Rene de Visser wrote:

"Ian Lynagh" schrieb im Newsbeitrag news:20110729182136.GA2345@matrix.chaos.earth.li...

...

We are pleased to announce the first release candidate for GHC 7.2.1:

Is it normal for the windows build to have 99 unexpected failures?

http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/289.html

I'm looking at these. Glancing at the failures, I'm sure a lot of them will turn out to be bugs in the testsuite, rather than in GHC. I count 14 distinct failures (the rest are duplicates of one of these 14). Cheers, Simon

On 3 August 2011 19:01, Jens Petersen wrote:

Thanks!  I have done a test build in Fedora's buildsystem: (Note this is a "bootstrap" build without shared libraries.)

Ok I did a more normal build today with shared libs and ran the testsuite too: http://koji.fedoraproject.org/koji/taskinfo?taskID=3251246 The test results for x86_64 are: "0 unexpected failures" :-) but there are "17 unexpected failures" for i686: Unexpected failures: ffi/should_run 1679 [bad exit code] (normal) ffi/should_run 2469 [bad exit code] (normal) ffi/should_run 2594 [bad exit code] (normal) ffi/should_run 4038 [bad exit code] (normal) ffi/should_run 4221 [bad exit code] (normal) ffi/should_run fed001 [bad exit code] (normal) ffi/should_run ffi006 [bad exit code] (normal) ffi/should_run ffi007 [bad exit code] (normal) ffi/should_run ffi008 [bad exit code] (normal) ffi/should_run ffi011 [bad exit code] (normal) ffi/should_run ffi013 [bad exit code] (normal) ffi/should_run ffi014 [bad exit code] (threaded1) ffi/should_run ffi019 [bad exit code] (normal) ffi/should_run ffi020 [bad exit code] (normal) rts 4850 [bad stdout] (normal) rts 5250 [bad exit code] (normal) rts T4059 [bad exit code] (normal) from http://koji.fedoraproject.org/koji/getfile?taskID=3251249&name=build.log . Note the Fedora build is patched to use system libffi. The packages can be downloaded and installed as described in the previous mail from http://kojipkgs.fedoraproject.org/scratch/petersen/task_3251246 Jens

On Thu, Aug 04, 2011 at 12:51:01PM +0100, Simon Marlow wrote:

On 04/08/2011 05:35, Jens Petersen wrote:

...

On 3 August 2011 19:01, Jens Petersen wrote:

Unexpected failures: [...] ffi/should_run fed001 [bad exit code] (normal) [...]

from http://koji.fedoraproject.org/koji/getfile?taskID=3251249&name=build.log .

The packages can be downloaded and installed as described in the previous mail from http://kojipkgs.fedoraproject.org/scratch/petersen/task_3251246

This looks like breakage in foreign import "wrapper". That's pretty serious - please open a ticket, and include as many details as possible.

The build log says: =====> fed001(normal) 634 of 2894 [0, 0, 0] cd ./ffi/should_run && '/builddir/build/BUILD/ghc-7.2.0.20110728/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -o fed001 fed001.hs >fed001.comp.stderr 2>&1 cd ./ffi/should_run && ./fed001 fed001.run.stdout 2>fed001.run.stderr /bin/sh: line 1: 32288 Segmentation fault ./fed001 < /dev/null > fed001.run.stdout 2> fed001.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for fed001(normal) but it works fine for me on x86/Linux.

...

Note the Fedora build is patched to use system libffi.

Hmm. What happens if you don't patch it? Thanks Ian

On 05/08/2011 08:45, Jens Petersen wrote:

On 5 August 2011 05:27, Ian Lynagh wrote:

...

...

...

from http://koji.fedoraproject.org/koji/getfile?taskID=3251249&name=build.log . | *** unexpected failure for fed001(normal)

but it works fine for me on x86/Linux.

...

...

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

I attach system libffi patch if anyone wants to look at it, but I don't see anything particularly arch-specific about it though so I still don't understand why it fails for 7.2. A similar patch for ghc-7.0.4 doesn't seem to have any ill-effects on the test results:

eg http://koji.fedoraproject.org/koji/buildinfo?buildID=248071

I'd be interested to know if any other distros can reproduces or not. I think the system libffi patch originally comes from Debian.

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. 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).

It would be good to make Linux default to use system libffi anyway. Is there any good reason not to do so? As you know copy libraries are frowned upon in the linux world. I can't remember if such an RFE already exists in trac?

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). 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). Cheers, Simon

On 05/08/2011 12:08, Joachim Breitner wrote:

Hi,

Am Freitag, den 05.08.2011, 09:46 +0100 schrieb Simon Marlow:

...

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). 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).

after this broad hint, I ran the full testsuite, getting this result on Debian:

OVERALL SUMMARY for test run started at Fr 5. Aug 11:02:03 CEST 2011 2894 total tests, which gave rise to 12535 test cases, of which 0 caused framework failures 2327 were skipped

9823 expected passes 351 expected failures 1 unexpected passes 33 unexpected failures

Unexpected passes: concurrent/should_run throwto002 (ghci)

Unexpected failures: cabal ghcpkg05 [bad stderr] (normal) concurrent/prog002 concprog002 [exit code non-0] (threaded2,threaded2_hT) concurrent/prog003 concprog003 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) concurrent/prog003 concprog003 [bad stdout or stderr] (ghci) concurrent/should_run conc023 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) concurrent/should_run conc023 [bad stdout or stderr] (ghci) ffi/should_run ffi009 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ffi/should_run ffi009 [bad stdout or stderr] (ghci) plugins plugins05 [exit code non-0] (profasm,dyn,profthreaded)

Without looking into details yet, or comparing it with the test suite in 7.0.4.

This result is fine. Most of those failures have been cleaned up in HEAD already, but the changes haven't been merged into the branch yet. Cheers, Simon

On 09/08/2011 05:59, Jens Petersen wrote:

...

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?

yes, please do. Cheers, Simon

I've just found http://hackage.haskell.org/trac/ghc/ticket/5377 which explains it. C. Am 05.08.2011 12:56, schrieb Christian Maeder:

Hi,

I've noticed that with ghc-7.2 many modules with LANGUAGE TypeSynonymInstances now also require FlexibleInstances

Two examples are in the HTTP package Network.TCP and Network.BufferType

Was ghc-7.0 wrong about this, before?

Cheers Christian

Am 29.07.2011 20:21, schrieb Ian Lynagh:

...

We are pleased to announce the first release candidate for GHC 7.2.1:

http://www.haskell.org/ghc/dist/7.2.1-rc1/

This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD.

Please test as much as possible; bugs are much cheaper if we find them before the release!

Thanks Ian, on behalf of the GHC team

On Tue, Aug 09, 2011 at 06:37:11PM +0200, Goetz Isenmann wrote:

please consider the following two patches for DragonFly support.

Applied, thanks. Thanks Ian