i second that On Mon, Mar 24, 2014 at 8:13 PM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote:

Awesome! Thanks for all the hard work!!

Manuel

Austin Seipp :

...

Hello all,

As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so.

Second, there are just two things I want to note:

- For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug.

- Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night.

In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist.

Anyway, the time is finally here, so let's get it over with!

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On 25/03/14 06:01, kyra wrote:

Will it include the latest commit to haddock? It solves this: http://trac.haskell.org/haddock/ticket/292. This can greatly improve performance of haddock in some situations (when a project is built with --split-obj flag).

Cheers, Kyra

On 3/25/2014 01:36, Austin Seipp wrote:

...

Hello all,

As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so.

Second, there are just two things I want to note:

- For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug.

- Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night.

In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist.

Anyway, the time is finally here, so let's get it over with!

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi, That commit is not in 2.14.1. Do you have any benchmarks to show the speedup? If the commit does some significant speedup, I'm not against backporting it into Haddock released with 7.8.2 (and there is at least 1 other fix I want to get into 7.8.2) but we pretty much closed the 2.14.1, it's up on Hackage and everything and that's what's planned to ship with 7.8.1. -- Mateusz K.

On 25/03/14 16:18, kyra wrote:

On 3/25/2014 19:11, Mateusz Kowalczyk wrote:

...

That commit is not in 2.14.1. Do you have any benchmarks to show the speedup? If the commit does some significant speedup, I'm not against backporting it into Haddock released with 7.8.2 (and there is at least 1 other fix I want to get into 7.8.2) but we pretty much closed the 2.14.1, it's up on Hackage and everything and that's what's planned to ship with 7.8.1.

Hmm, now, when I'm trying to reproduce things I don't see haddock producing any assembly output let alone split it when using 7.8rc2 haddock.

It seemed to me some time ago haddock became slow when processing a package built with --enable-split-objs and I've decided to look into things and discovered haddock wants .hi interface files and produces assembly output to produce these interface files.

I was extremely surprised, rechecked things several times and saw the same picture.

Now I can't reproduce this at all.

If haddock never produced .hi interface files and/or assembly output then that was some mental aberration and the whole story can be dropped.

Regards, Kyra

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

As far as I know (and this is mostly guessing), Haddock will ask GHC to produce .hi files when they do not already exist. I think you might have some luck if you simply try cabal configure && cabal haddock but I don't know. I took the patch because I saw no harm in it and all tests were passing but I do admit that I did not check the performance gain (we don't have benchmarks, perhaps we should hook some up) or loss. I think GHC has some Haddock perf tests but I did not check the numbers and I don't think it would even fall under that. If you can come up with something then let me know. If you can't, I think we'll keep the patch just in case unless someone can show it breaks something. The only instances of Haddock becoming really slow that I can think of is some rather old ticket (#101 on Haddock Trac) in presence of Template Haskell but I have closed it a while ago due to lack of information to go on and inability to replicate without the reporter's help. Perhaps this was your use case? -- Mateusz K.

On 25/03/14 17:09, kyra wrote:

On 3/25/2014 20:52, Mateusz Kowalczyk wrote:

...

The only instances of Haddock becoming really slow that I can think of is some rather old ticket (#101 on Haddock Trac) in presence of Template Haskell but I have closed it a while ago due to lack of information to go on and inability to replicate without the reporter's help. Perhaps this was your use case?

Aha, this is why I could not reproduce it! I checked it on packages which used no TH, and that slow behaviour occurred when TH was involved!

I think it is TH which really triggers producing and splitting of an assembly output and in this case no-splitting gives *huge* benefit. Sadly, I have no time to check this right now.

Regards, Kyra

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

There's no rush as it's not going to get into 7.8.1 anyway but I would love to see some numbers before 7.8.2 so please keep us in mind. Thanks! -- Mateusz K.

Hi all, One final update: I have found a workaround for the issue Mateusz reported last week. Luckily it can be fought off somewhat easily for now for OS X users, but there are more details here: https://github.com/haskell/cabal/issues/1740 The final thing that ended up being a hold-up is now #8870 - the 32bit Windows distribution is segfaulting. At first, I thought this was an anomaly, but I saw several other people who also reported this problem. After a bit of sweat I've finally reproduced this bug and tracked this down part of the way, but I've been especially confused by this issue because apparently it does not affect everyone! Which is quite bizarre, as given the results I found, I'd suspect everyone to see it. Right now, Kyrill has suggested a fix I'm attempting (I slightly botched my first try), and I have found a way to avoid it at the moment by turning off optimization (which seems to reduce stack pressure enough to get by on Windows - see the ticket for details). Are there any Windows users who would be willing to test a 32bit Windows binary distribution, should I make a provisional one? I can have it up within a few hours from now. I'd really love some outside confirmation of this problem and a resolution once we have it! As this is the last bug, if I can at least get some confirmation a fix works, I can have the final release out immediately afterwords - the tree is otherwise quiet and will remain so. On Tue, Mar 25, 2014 at 5:24 PM, Austin Seipp wrote:

Hello all,

As an updated, I'm looking into the report Mateusz had of 'free' failing to build haddocks on OS X*, which I've reproduced. It seems nasty - I'll follow up with details ASAP.

* See his recent email to ghc-devs about this problem.

On Tue, Mar 25, 2014 at 12:11 PM, Mateusz Kowalczyk wrote:

...

On 25/03/14 17:09, kyra wrote:

...

On 3/25/2014 20:52, Mateusz Kowalczyk wrote:

...

The only instances of Haddock becoming really slow that I can think of is some rather old ticket (#101 on Haddock Trac) in presence of Template Haskell but I have closed it a while ago due to lack of information to go on and inability to replicate without the reporter's help. Perhaps this was your use case?

Aha, this is why I could not reproduce it! I checked it on packages which used no TH, and that slow behaviour occurred when TH was involved!

I think it is TH which really triggers producing and splitting of an assembly output and in this case no-splitting gives *huge* benefit. Sadly, I have no time to check this right now.

Regards, Kyra

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

There's no rush as it's not going to get into 7.8.1 anyway but I would love to see some numbers before 7.8.2 so please keep us in mind.

Thanks!

-- Mateusz K. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Oh excellent, thank you for the tip Kyrill, I had no idea about this! My build is on the way, so I will try this and report back soon. On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote:

On 4/3/2014 17:15, Austin Seipp wrote:

...

Right now, Kyrill has suggested a fix I'm attempting (I slightly botched my first try), and I have found a way to avoid it at the moment by turning off optimization (which seems to reduce stack pressure enough to get by on Windows - see the ticket for details).

It's absolutely not necessary to rebuild everything to check if this works, it's enough to edit ghc.exe with peflags utility (which has --stack-reserve and --stack-commit options) and look if it stop segfaulting. If I could reproduce the problem I'd have done this long ago.

Cheers,

Kyra

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Btw, it is committed size which is important here. I proposed to increase both only to follow Linux/OSX linker policy which sets stack size to be 8mb by default, otherwise we could stay at 1mb for both reserved (windows' default value) and committed values. Regards, Kyra On 03.04.2014 18:00, Austin Seipp wrote:

Kyrill, you are fantastic! I confirmed this incantation seems to have fixed the problem on my build:

$ peflags --stack-reserve=0x200000 --stack-commit=0x200000 ghc.exe

with the RC2 build, and not my own. Hooray!

I will work up something soon. Thanks so much again!

On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp wrote:

...

Oh excellent, thank you for the tip Kyrill, I had no idea about this! My build is on the way, so I will try this and report back soon.

On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote:

...

On 4/3/2014 17:15, Austin Seipp wrote:

...

Right now, Kyrill has suggested a fix I'm attempting (I slightly botched my first try), and I have found a way to avoid it at the moment by turning off optimization (which seems to reduce stack pressure enough to get by on Windows - see the ticket for details). It's absolutely not necessary to rebuild everything to check if this works, it's enough to edit ghc.exe with peflags utility (which has --stack-reserve and --stack-commit options) and look if it stop segfaulting. If I could reproduce the problem I'd have done this long ago.

Cheers,

Kyra

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Ah, sorry. Now the policy is to set it to 2mb then. Cheers, Kyra On 03.04.2014 18:50, Austin Seipp wrote:

Actually, the 0x200000 for the reserve was just the default in the executable - I just set it out based on what peflags told me initially.

Thank you again Kyrill!

On Thu, Apr 3, 2014 at 9:32 AM, kyra wrote:

...

Btw, it is committed size which is important here. I proposed to increase both only to follow Linux/OSX linker policy which sets stack size to be 8mb by default, otherwise we could stay at 1mb for both reserved (windows' default value) and committed values.

Regards, Kyra

On 03.04.2014 18:00, Austin Seipp wrote:

...

Kyrill, you are fantastic! I confirmed this incantation seems to have fixed the problem on my build:

$ peflags --stack-reserve=0x200000 --stack-commit=0x200000 ghc.exe

with the RC2 build, and not my own. Hooray!

I will work up something soon. Thanks so much again!

On Thu, Apr 3, 2014 at 8:50 AM, Austin Seipp wrote:

...

Oh excellent, thank you for the tip Kyrill, I had no idea about this! My build is on the way, so I will try this and report back soon.

On Thu, Apr 3, 2014 at 8:34 AM, kyra wrote:

...

On 4/3/2014 17:15, Austin Seipp wrote:

...

Right now, Kyrill has suggested a fix I'm attempting (I slightly botched my first try), and I have found a way to avoid it at the moment by turning off optimization (which seems to reduce stack pressure enough to get by on Windows - see the ticket for details). It's absolutely not necessary to rebuild everything to check if this works, it's enough to edit ghc.exe with peflags utility (which has --stack-reserve and --stack-commit options) and look if it stop segfaulting. If I could reproduce the problem I'd have done this long ago.

Cheers,

Kyra

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hello all, The source distribution is now available: http://www.haskell.org/ghc/dist/7.8.1/ Feel free to make builds - I'll add them as they come in and will announce soon... On Thu, Apr 3, 2014 at 1:39 PM, Mateusz Kowalczyk wrote:

On 25/03/14 06:01, kyra wrote:

...

Will it include the latest commit to haddock? It solves this: http://trac.haskell.org/haddock/ticket/292. This can greatly improve performance of haddock in some situations (when a project is built with --split-obj flag).

Cheers, Kyra

Just as a follow up, as we had some more time, this is actually going into 7.8.1.

Thanks

-- Mateusz K. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Well said Johan! Thanks to Austin and to everyone (eg our "build bots" :) that helped him navigate these cockroaches -- these bugs seemed very resilient! On Tue, Apr 8, 2014 at 8:30 AM, Johan Tibell wrote:

On Tue, Apr 8, 2014 at 3:28 PM, Austin Seipp wrote:

...

Hello all,

The source distribution is now available:

http://www.haskell.org/ghc/dist/7.8.1/

Feel free to make builds - I'll add them as they come in and will announce soon...

Thanks for all your hard work Austin.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

2014-04-08 15:28 GMT+02:00 Austin Seipp :

Feel free to make builds - I'll add them as they come in and will announce soon...

The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual: http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html

Hi, I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than. https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris... sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 Regards, Pavel Ryzhov On 08 Apr 2014, at 21:39, Carter Schonwald wrote:

ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unoffici...

On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János wrote: 2014-04-08 15:28 GMT+02:00 Austin Seipp :

...

Feel free to make builds - I'll add them as they come in and will announce soon...

The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual:

http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi Karel, That is great! Do you know if there any plans for 64-bit build of GHC for Solaris 11? Regards, Pavel On 09 Apr 2014, at 10:49, Karel Gardas wrote:

Hi Pavel,

I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs.

Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk

Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi

The first link is binary tarball while the second is sha256.

Karel

On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote:

...

Hi,

I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than.

https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris... sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2

Regards, Pavel Ryzhov

On 08 Apr 2014, at 21:39, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

...

ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unoffici...

On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János mailto:pali.gabor@gmail.com> wrote:

2014-04-08 15:28 GMT+02:00 Austin Seipp mailto:austin@well-typed.com>:

...

Feel free to make builds - I'll add them as they come in and will announce soon...

The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual:

http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi, thanks to an advice put by Alain (cced), I've grabbed the copy of SmartOS and installed GHC there. It looks like this package is AMD64 based. I've then moved it to my Solaris 11.1 and it runs fine and compile the code well: $ ghc --make HelloWorld.lhs [1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o ) Linking HelloWorld ... $ ./HelloWorld Hello world! $ file HelloWorld HelloWorld: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped $ ldd HelloWorld libiconv.so.2 => /opt/local/lib/libiconv.so.2 libgmp.so.10 => /opt/local/lib/libgmp.so.10 libm.so.2 => /lib/64/libm.so.2 librt.so.1 => /lib/64/librt.so.1 libdl.so.1 => /lib/64/libdl.so.1 libc.so.1 => /lib/64/libc.so.1 libumem.so.1 => /lib/64/libumem.so.1 libgcc_s.so.1 => /opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1 Well, so this is IMHO a easier way to bootstrap GHC HEAD on Solaris/AMD64. I currently do not have a time to deal with it, but hopefully will find some during the weekend -- well, if nobody is faster, otherwise I will devote my "weekend ghc hobby" time to SPARC NCG debugging. :-) Cheers, Karel On 04/10/14 09:39 AM, Christian Maeder wrote:

Hi,

I've tried to cross-compile https://ghc.haskell.org/trac/ghc/ticket/8910 but did not succeed, yet.

There seem to be problems with Int64 and/or Word data types. The proper start would be to make a careful comparison of the test-suite results, but there are already failures for the 32bit version (under Solaris 10). Unfortunately I don't have time to look into it further.

Cheers Christian

Am 09.04.2014 16:49, schrieb Pavel Ryzhov:

...

Hi Karel,

That is great!

Do you know if there any plans for 64-bit build of GHC for Solaris 11?

Regards, Pavel

On 09 Apr 2014, at 10:49, Karel Gardas wrote:

...

Hi Pavel,

I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs.

Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk

Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi

The first link is binary tarball while the second is sha256.

Karel

On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote:

...

Hi,

I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than.

https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris...

sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2

Regards, Pavel Ryzhov

On 08 Apr 2014, at 21:39, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

...

ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unoffici...

On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János mailto:pali.gabor@gmail.com> wrote:

2014-04-08 15:28 GMT+02:00 Austin Seipp mailto:austin@well-typed.com>:

...

Feel free to make builds - I'll add them as they come in and will announce soon...

The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual:

http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2

http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi Karel, usually I do not build HEAD. My attempt starting to do so failed as follows: git clone git://git.haskell.org/ghc.git cd ghc ./sync-all get autoreconf ./configure gmake ... ghc.mk:690: libraries/haskeline/ghc.mk: Datei oder Verzeichnis nicht gefunden libraries/dph/ghc.mk:134: *** dph_th_deps(v): libraries/dph/dph-base_dist-install_GHCI_LIB not defined!. Schluss. gmake: *** [all] Fehler 2 Is there somewhere a x86_64-solaris2 binary-dist (for Solaris 10) to try out first? Cheers Christian Am 14.07.2014 08:24, schrieb Karel Gardas:

Folks,

thanks to 64bit GHC binaries provided by Alain's SmartOS builder I've been able to hack GHC to compile well on/for x86_64-solaris platform. Austin already merged the support into GHC HEAD, see https://phabricator.haskell.org/rGHC6da603213b097a267418d8c14cbfaf0021ac2b2c

It would be great if you also give it a try and test on your systems or with cross-compiling without a need to install SmartOS libraries.

Thanks! Karel

On 04/10/14 09:39 AM, Christian Maeder wrote:

...

Hi,

I've tried to cross-compile https://ghc.haskell.org/trac/ghc/ticket/8910 but did not succeed, yet.

There seem to be problems with Int64 and/or Word data types. The proper start would be to make a careful comparison of the test-suite results, but there are already failures for the 32bit version (under Solaris 10). Unfortunately I don't have time to look into it further.

Cheers Christian

Am 09.04.2014 16:49, schrieb Pavel Ryzhov:

...

Hi Karel,

That is great!

Do you know if there any plans for 64-bit build of GHC for Solaris 11?

Regards, Pavel

I've described my attempt in the ticket: https://ghc.haskell.org/trac/ghc/ticket/8910 In case someone wants to investigate the core dump further I've put the binary-dist of the initial cross-compiler here: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... (will be removed after a while as it is not suited for normal use) C. Am 14.07.2014 15:16, schrieb Karel Gardas:

On 07/14/14 02:53 PM, Christian Maeder wrote:

...

Hi Karel,

usually I do not build HEAD. My attempt starting to do so failed as follows:

git clone git://git.haskell.org/ghc.git cd ghc ./sync-all get autoreconf

^ I'm not sure, but shouldn't that be `perl boot' ?

...

./configure

^ if you don't have x86_64-solaris ghc yet on your system, you will probably need to cross-compile with --target= param.

...

Is there somewhere a x86_64-solaris2 binary-dist (for Solaris 10) to try out first?

I haven't tried that yet as my primary target is Solaris 11.

Karel

On 07/16/14 10:28 PM, Alain O'Dea wrote:

...

...

Is there somewhere a x86_64-solaris2 binary-dist (for Solaris 10) to try out first?

I haven't tried that yet as my primary target is Solaris 11.

If you target Solaris 10 it should work on Solaris 11 as well. That's what the JRE and JDK do. That's only workable if there isn't some specific significant advantage in APIs/libraries unique to Solaris 11.

Yes, Solaris 10 -> Solaris 11 works. Thanks to nice work of Sun folks even Solaris 11 -> Solaris 10 sometimes works too. Anyway, now, my priority is to get Solaris 11/AMD64 builder up'n'running. It looks like it's hit by inconsistency in #ifdef GHCI symbols in TcSplice.lhs/lhs-boot files[1]. Anyway, this inconsistency shows that something is broken on build process which I'll need to track down. Once this is done, I'll attempt to build Solaris 11 binary dist but with GHC provided static libffi/libgmp libraries. Such build worked on Solaris 10 well in the past and it may be the cheapest route to go that time... Karel [1]: http://haskell.inf.elte.hu/builders/solaris-amd64-head/5/10.html

On 9 April 2014 14:48, Jens Petersen wrote:

On 8 April 2014 22:28, Austin Seipp wrote:

...

The source distribution is now available: http://www.haskell.org/ghc/dist/7.8.1/

It builds fine on Fedora 21 devel for x86_64 and i686, but unfortunately it

fails on ARM with:

inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted

See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for the full build.log, etc. I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed.

I tested and this also happens on Fedora 20 ARM [1] so I now doubt it could be due to any recent changes in Fedora devel (Rawhide). I filed https://ghc.haskell.org/trac/ghc/ticket/8976. Anyway I suppose it may be too late to fix for the 7.8.1 release but hopefully soon for 7.8.2. Jens [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720188

On 9 April 2014 17:53, Karel Gardas wrote:

Ben Gamari (cced) documented it well here: http://bgamari.github.io/ posts/2014-03-06-compiling-ghc-7.8-on-arm.html

Looks like the issue is caused by binutils' linker while fixed in gold.

Thanks a lot, Karel! I will try Ben's hack later. I am still surprised that RC2 builds fine on ARM (I re-verified that yesterday [1]) but not final 7.8.1. Were there some late ARM or linking changes that cause this now? On 04/ 9/14 10:21 AM, Jens Petersen wrote:

...

dll-split: internal error: evacuate(static): strange closure type 0

See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for

...

I reproduced this two times now. RC2 built okay on ARM so I am not

...

sure what changed.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331

Hi Austin/all, Here's GHC iOS 7.8.1 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1-device/gh... (sha 4b98f55212b33296ed9d59d7e30eaa12d7a34a3b) https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1/ghc-7.8.1... (sha bcd213b4da15f77aaa4b1b06c51867785f262002) and README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Cheers Luke On Wed, Apr 9, 2014 at 6:09 PM, Austin Seipp wrote:

Jens,

It's probably due to abb86adf7f749b3d44887d28bc96b43c5a1e0631[1] which was merged post RC2. I base this on the fact your build is failing during the dynamic build. Do try a reverse patch and see if it helps.

I believe Karel is right - you just need to use Gold. Ben actually had patches to make the build fail if using binutils ld was detected, but I believe I had reservations about the patch which I cannot recall off the top of my head. In any case, a fix like that can certainly go in 7.8.2.

Do let us know how it goes.

[1] https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631

On Wed, Apr 9, 2014 at 8:03 PM, Jens Petersen wrote:

...

On 9 April 2014 17:53, Karel Gardas wrote:

...

Ben Gamari (cced) documented it well here: http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html

Looks like the issue is caused by binutils' linker while fixed in gold.

Thanks a lot, Karel! I will try Ben's hack later.

I am still surprised that RC2 builds fine on ARM (I re-verified that yesterday [1]) but not final 7.8.1. Were there some late ARM or linking changes that cause this now?

...

On 04/ 9/14 10:21 AM, Jens Petersen wrote:

...

dll-split: internal error: evacuate(static): strange closure type 0

...

See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for

...

...

I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs