Carter Schonwald writes:

heres my OSX build that matches up with that RC4 commit / 8.0 tip https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-...

$ shasum -a512 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz 3ecd0a9c4578ac38883de03f66e8d86955368eec2bea52a409de0053386b53c89ac954b2806ef5ac73bb924d62821ce685ff5301b780646fedd45c99d5942a90 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

Thanks Carter! Cheers, - Ben

Thanks Carter. I'm not so concerned with obtaining a working build. I'd like to be able to build with the Apple toolchain. I assume there are other developers who feel the same. Can you elaborate on the "path to nm classic is wrong" ? Cheers George On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

I've a working build I'll circulate Also that path to nm classic is wrong.

On Saturday, April 23, 2016, George Colpitts wrote:

...

I'm having problems using the Apple toolchain to build this on Mac OS. Has anybody succeeded with the Apple toolchain?

First I get the error:

broken 'nm' detected, see https://ghc.haskell.org/ticket/11744. Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

but after I try that workaround I get:

inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm-classic" --target-os "darwin" deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory) make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

Thanks George

On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari wrote:

...

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1-rc4/

For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

i'm running into some confusions with getting docs built correclty / not generating the pdfs and html assets i expect, i'll share an updated sha etc when i track that down On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts wrote:

retrying with

./configure --with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

On Sat, Apr 23, 2016 at 10:49 AM George Colpitts < george.colpitts@gmail.com> wrote:

...

Thanks Carter. I'm not so concerned with obtaining a working build. I'd like to be able to build with the Apple toolchain. I assume there are other developers who feel the same.

Can you elaborate on the "path to nm classic is wrong" ?

Cheers George

On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

I've a working build I'll circulate Also that path to nm classic is wrong.

On Saturday, April 23, 2016, George Colpitts wrote:

...

I'm having problems using the Apple toolchain to build this on Mac OS. Has anybody succeeded with the Apple toolchain?

First I get the error:

broken 'nm' detected, see https://ghc.haskell.org/ticket/11744. Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

but after I try that workaround I get:

inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm-classic" --target-os "darwin" deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory) make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

Thanks George

On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari wrote:

...

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1-rc4/

For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

err, i mean, sphinx was giving checking for version of sphinx-build... Sphinx (sphinx-build) 1.4.1 ./configure: line 9698: test: Sphinx (sphinx-build) 1: integer expression expected which version of sphinx for which python are we supposed to use? On Sat, Apr 23, 2016 at 12:18 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

looks like i dont have dblatex setup on that build machine, fixing that now! (slightly trick on mac)

On Sat, Apr 23, 2016 at 11:51 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

i'm running into some confusions with getting docs built correclty / not generating the pdfs and html assets i expect, i'll share an updated sha etc when i track that down

On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts < george.colpitts@gmail.com> wrote:

...

retrying with

./configure --with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

On Sat, Apr 23, 2016 at 10:49 AM George Colpitts < george.colpitts@gmail.com> wrote:

...

Thanks Carter. I'm not so concerned with obtaining a working build. I'd like to be able to build with the Apple toolchain. I assume there are other developers who feel the same.

Can you elaborate on the "path to nm classic is wrong" ?

Cheers George

On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

I've a working build I'll circulate Also that path to nm classic is wrong.

On Saturday, April 23, 2016, George Colpitts < george.colpitts@gmail.com> wrote:

...

I'm having problems using the Apple toolchain to build this on Mac OS. Has anybody succeeded with the Apple toolchain?

First I get the error:

broken 'nm' detected, see https://ghc.haskell.org/ticket/11744. Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

but after I try that workaround I get:

inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm-classic" --target-os "darwin" deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory) make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

Thanks George

On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari wrote:

> tl;dr: If you would like to produce a binary distribution for GHC > 8.0.1-rc4 then let us know, grab the source distribution and > start building. The binary distributions will be all released > one > week from today. > > Hello GHC packagers, > > I am happy to announce the release of the 8.0.1-rc4 source > distribution > to binary packagers. This release should resolve all of the issues > noted > in the release candidate 3 announcement. You will find the usual > artifacts at > > http://downloads.haskell.org/~ghc/8.0.1-rc4/ > > For this candidate we are again following our new release policy [1], > with a one-week delay between the release of the source and binary > distributions. The goal of this policy is to give all platforms the > opportunity for support from the first day of a release. > > If all of the expected binary releases are submitted before the > week-long delay has elapsed, we will move forward with the release of > the binaries on an accelerated schedule. It would be appreciated if > you > could reply to this message confirming that you intend to offer a > binary > distribution this release. > > Otherwise, let either Austin or I know if you have any trouble > building > your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case > we > encounter unexpected issues but all of my builds with this tarball > thusfar have gone quite well. > > Good luck and thanks for all of your work! > > Cheers, > > - Ben > > > [1] > https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

ok, its detecting my python3 sphinx 1.4 install, but also looks like the autoconf is getting confused FP_COMPARE_VERSIONS([$fp_cv_sphinx_version],-lt,1.0.0, [AC_MSG_WARN([Sphinx version 1.0.0 or later is required to build documentation]); SPHINXBUILD=;]) seems to be the relevant bit, though its setting the config correctly now I *believe * On Sat, Apr 23, 2016 at 12:25 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

fixed up the sphinx confusion...

seems we need the python 2.7 sphinx installed? (or at least, it wasn't checking sphinx correctly to handle the version supported in the python 3 series?!)

On Sat, Apr 23, 2016 at 12:23 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

err, i mean, sphinx was giving checking for version of sphinx-build... Sphinx (sphinx-build) 1.4.1 ./configure: line 9698: test: Sphinx (sphinx-build) 1: integer expression expected

which version of sphinx for which python are we supposed to use?

On Sat, Apr 23, 2016 at 12:18 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

looks like i dont have dblatex setup on that build machine, fixing that now! (slightly trick on mac)

On Sat, Apr 23, 2016 at 11:51 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

i'm running into some confusions with getting docs built correclty / not generating the pdfs and html assets i expect, i'll share an updated sha etc when i track that down

On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts < george.colpitts@gmail.com> wrote:

...

retrying with

./configure --with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

On Sat, Apr 23, 2016 at 10:49 AM George Colpitts < george.colpitts@gmail.com> wrote:

...

Thanks Carter. I'm not so concerned with obtaining a working build. I'd like to be able to build with the Apple toolchain. I assume there are other developers who feel the same.

Can you elaborate on the "path to nm classic is wrong" ?

Cheers George

On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

> I've a working build I'll circulate > Also that path to nm classic is wrong. > > > On Saturday, April 23, 2016, George Colpitts < > george.colpitts@gmail.com> wrote: > >> I'm having problems using the Apple toolchain to build this on Mac >> OS. Has anybody succeeded with the Apple toolchain? >> >> First I get the error: >> >> broken 'nm' detected, see https://ghc.haskell.org/ticket/11744 >> . >> Workaround: You may want to pass '--with-nm=nm-classic' to >> 'configure'. >> >> but after I try that workaround I get: >> >> inplace/bin/deriveConstants --gen-header -o >> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir >> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" >> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag >> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist >> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag >> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon >> --nm-program "nm-classic" --target-os "darwin" >> deriveConstants: nm-classic: readCreateProcess: >> runInteractiveProcess: exec: does not exist (No such file or directory) >> make[1]: *** >> [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 >> make[1]: *** Waiting for unfinished jobs.... >> make: *** [all] Error 2 >> >> Thanks >> George >> >> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari >> wrote: >> >>> tl;dr: If you would like to produce a binary distribution for GHC >>> 8.0.1-rc4 then let us know, grab the source distribution and >>> start building. The binary distributions will be all >>> released one >>> week from today. >>> >>> Hello GHC packagers, >>> >>> I am happy to announce the release of the 8.0.1-rc4 source >>> distribution >>> to binary packagers. This release should resolve all of the issues >>> noted >>> in the release candidate 3 announcement. You will find the usual >>> artifacts at >>> >>> http://downloads.haskell.org/~ghc/8.0.1-rc4/ >>> >>> For this candidate we are again following our new release policy >>> [1], >>> with a one-week delay between the release of the source and binary >>> distributions. The goal of this policy is to give all platforms the >>> opportunity for support from the first day of a release. >>> >>> If all of the expected binary releases are submitted before the >>> week-long delay has elapsed, we will move forward with the release >>> of >>> the binaries on an accelerated schedule. It would be appreciated >>> if you >>> could reply to this message confirming that you intend to offer a >>> binary >>> distribution this release. >>> >>> Otherwise, let either Austin or I know if you have any trouble >>> building >>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in >>> case we >>> encounter unexpected issues but all of my builds with this tarball >>> thusfar have gone quite well. >>> >>> Good luck and thanks for all of your work! >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] >>> https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>

Thomie (Thomas M?) pointed out that there may have been a "are-validating" make file in my /mk/ dir that could have been messing with things. i've gotten a build i'm happy with, i'm now seeing if i can tweak it to have the otool -L output favor stuff in /usr/lib (ie mac standard stuff) vs userland overlays for some basic linker stuff On Sat, Apr 23, 2016 at 6:43 PM, Ben Gamari wrote:

Carter Schonwald writes:

...

ok, its detecting my python3 sphinx 1.4 install, but also looks like the autoconf is getting confused FP_COMPARE_VERSIONS([$fp_cv_sphinx_version],-lt,1.0.0, [AC_MSG_WARN([Sphinx version 1.0.0 or later is required to build documentation]); SPHINXBUILD=;]) seems to be the relevant bit, though its setting the config correctly now I *believe*

Hmm, did you ever work out what was going on here? I've built with both Python 2 and Python 3 Sphinx installations and had no trouble in either case. That being said, this was on Linux so this data point may not mean much on OS X.

Cheers,

- Ben

I'll try to collect my thoughts and tease out what did/didn't work tomorrow, in the mean time, here's a build I believe should work for everyone on mac and should have full docs, http://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-u... shasum -a512 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz 969eb2914b9c7c31bcdfb814aac34f0dcd9d6c8d7b9e7affe1605985e9de543d911dc6dae0fa05a32da12150d56488e56ad6fbf4d1f818ec84f7a4759d876c95 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz one niggling issue is that, at least based upon the output of otool -L, the builds point to /usr/local/lib/gcc/6/libgcc_s.1.dylib (my userland GCC leaking through) and I *believe* but could be wrong that its better to have it point to /usr/lib/libgcc_s.1.dylib or something? otoh, the otool -L output of those respective things are VERY different I will investigate that further, though its orthogonal to my doc building confusion that I still need to work out what happened with On Sat, Apr 23, 2016 at 6:57 PM, Ben Gamari wrote:

Carter Schonwald writes:

...

Thomie (Thomas M?) pointed out that there may have been a "are-validating" make file in my /mk/ dir that could have been messing with things.

i've gotten a build i'm happy with, i'm now seeing if i can tweak it to have the otool -L output favor stuff in /usr/lib (ie mac standard stuff) vs userland overlays for some basic linker stuff

Could you elaborate a bit here?

If there are manual tweaks applied to the build then we need to make sure they are documented (or ideally scripted, with the script in a publicly accessible, version controlled location), especially if we want to offer your build in some "official" capacity.

Cheers,

- Ben

On Sat, Apr 23, 2016 at 8:05 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

and I *believe* but could be wrong that its better to have it point to /usr/lib/libgcc_s.1.dylib or something? otoh, the otool -L output of those respective things are VERY different

People will need to have that libgcc_s.1.dylib *by path* installed. Apple's is likely too old to be compatible, so copying it or using install_name_tool to repoint to it will likely lead to a non-working program. You mentioned at one point that you built using a local gcc install. gcc uses its bundled libgcc_s; so you will have that dependency unless you switch to /usr/bin/clang to build. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Sat, Apr 23, 2016 at 8:50 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

It *seemed* to work fine even with that lib no longer at that path, but famous last words. It does seem that it doesn't do anything

It's only used when it needs to do something for which the CPU lacks support so a call to an emulation is used instead of trying to generate native code for it. Maybe you got lucky and ghc doesn't actually need it in its C bits. Or maybe it'll explode only when there's a full moon in Scorpio and Mars is ascendant. :/ (Well, when some rarely used operation happens to need something that x86_64 needs help with. I don't think there are many of those --- which means it's going to be an even rarer explosion.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/darwin-64.c If my understanding of the code is correct, there's no problems ! :) On Saturday, April 23, 2016, Carter Schonwald wrote:

I guess I have some spelunking to do tomorrow

It looks like apples libgcc may be some sort of clang thingy.

On Saturday, April 23, 2016, Brandon Allbery javascript:_e(%7B%7D,'cvml','allbery.b@gmail.com');> wrote:

...

On Sat, Apr 23, 2016 at 8:50 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

It *seemed* to work fine even with that lib no longer at that path, but famous last words. It does seem that it doesn't do anything

It's only used when it needs to do something for which the CPU lacks support so a call to an emulation is used instead of trying to generate native code for it. Maybe you got lucky and ghc doesn't actually need it in its C bits. Or maybe it'll explode only when there's a full moon in Scorpio and Mars is ascendant. :/ (Well, when some rarely used operation happens to need something that x86_64 needs help with. I don't think there are many of those --- which means it's going to be an even rarer explosion.)

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

it looks like the last bit i need to audit is https://github.com/gcc-mirror/gcc/blob/master/libgcc/config.host#L569-L572 and then just run some experiments tomorrow :) On Sat, Apr 23, 2016 at 9:46 PM, Brandon Allbery wrote:

On Sat, Apr 23, 2016 at 9:44 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

If my understanding of the code is correct, there's no problems ! :)

I have to admit I was wondering if it was just a stub to keep the rest of gcc / crt0/crtn happy....

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

George Colpitts writes:

retrying with

./configure --with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

Hi George, Did this work out for you? Indeed the advice given by the error message may be a bit misleading (as nm-classic may not be in PATH). Let me know if you have any suggestions for how to improve the message. Thanks for trying the build and sorry for the late reply! Cheers, - Ben

oddly enough the suggestions in the release notes for 8.0 have the correct path suggestion, I guess that the command line got out of sync On Sat, Apr 23, 2016 at 4:11 PM, George Colpitts wrote:

The error message should be changed from

Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

to

Workaround: You may want to pass '--with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to 'configure'.

Once I did that (as documented in https://ghc.haskell.org/ticket/11744) I was able to do a build

Cheers George

On Sat, Apr 23, 2016 at 10:37 AM George Colpitts < george.colpitts@gmail.com> wrote:

...

I'm having problems using the Apple toolchain to build this on Mac OS. Has anybody succeeded with the Apple toolchain?

First I get the error:

broken 'nm' detected, see https://ghc.haskell.org/ticket/11744. Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

but after I try that workaround I get:

inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm-classic" --target-os "darwin" deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory) make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

Thanks George

On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari wrote:

...

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1-rc4/

For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

George Colpitts writes:

The error message should be changed from

Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

to

Workaround: You may want to pass '--with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to 'configure'.

Once I did that (as documented in https://ghc.haskell.org/ticket/11744) I was able to do a build

Hmm, although I just checked on our OS X test box (which has the command-line tools installed, not full XCode) and it seems that the /Library/Developer/CommandLineTools/Toolchains directory doesn't exist. Presumably this is a (rather unfortunate) difference between full XCode and the command-line package. Do you know whether there is some advice that we might be able to offer that will work in both cases? If not I suspect we should just go with your suggestion; the full-XCode case is the far more likely of the two. Cheers, - Ben

Brandon Allbery writes:

On Sat, Apr 23, 2016 at 6:49 PM, Ben Gamari wrote:

...

Hmm, although I just checked on our OS X test box (which has the command-line tools installed, not full XCode) and it seems that the /Library/Developer/CommandLineTools/Toolchains directory doesn't exist. Presumably this is a (rather unfortunate) difference between full XCode and the command-line package. Do you know whether there is some advice that we might be able to offer that will work in both cases?

There doesn't seem to be an nm-classic corresponding to the Command Line Tools. In 10.11 at least, that package name is a misnomer; the command line utilities are part of the base system (com.apple.pkg.Essentials) and the SDK package is just includes and libs. There's no nm-classic hidden in either of them.

Ahh, this is useful. Thanks! In that case I suppose I need to work out how to install the full XCode package via the command line. If you have any pointers for this it would be greatly appreciated. Cheers, - Ben

Brandon Allbery writes:

On Sat, Apr 23, 2016 at 7:05 PM, Ben Gamari wrote:

...

In that case I suppose I need to work out how to install the full XCode package via the command line.

Uh, it's Apple. They don't *do* that. No Apple-sanctioned CLI access to the App Store (but see https://github.com/argon/mas --- note need to sign in to it with an Apple ID before use), and need to web login with an Apple ID and some level (including free) of developer registration to get it from developer.apple.com.

Sigh, that is what I was afraid of that. I guess we'll have to work something out. Thanks! Cheers, - Ben

that build confusion aside: https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-... shasum -a512 ghc-8.0.1-x86_64-apple-darwin-gcc5.tar.xz 54025a674cf95eaf5f26f46617164592266b76f17c740f17feb134208c7e6e25d1b685a9fc95877a3449c0e496492d8a55da2dae6ddade6a8cc8de8441415073 is the hash of the build i've uploaded On Wed, May 11, 2016 at 1:02 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such file or directory whats that about? i can try to poke at it this evening too

On Wed, May 11, 2016 at 11:33 AM, Ben Gamari wrote:

...

...

[ Unknown signature status ] tl;dr: If you would like to produce a binary distribution for GHC 8.0.1 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to at long last announce the release of the 8.0.1 source distribution to binary packagers. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from GHC commit

e99c1e2516aeb283172c7e6898508238e33cf065.

For this release we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution for this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. As usual I'll hold off on pushing the release git tag until we have a few binaries built in case we encounter unexpected issues.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Sorry maybe I did hit it when I did a make install, it ended cp: utils/haddock/doc/haddock: No such file or directory bash-3.2$ Carter, not sure if that is the same issue you encountered Thanks George On Wed, May 11, 2016 at 4:42 PM George Colpitts wrote:

I didn't hit that issue AFAIK, the build seemed to go fine (on a mac)

On Wed, May 11, 2016 at 2:03 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such file or directory whats that about? i can try to poke at it this evening too

On Wed, May 11, 2016 at 11:33 AM, Ben Gamari wrote:

...

...

[ Unknown signature status ] tl;dr: If you would like to produce a binary distribution for GHC 8.0.1 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to at long last announce the release of the 8.0.1 source distribution to binary packagers. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from GHC commit

e99c1e2516aeb283172c7e6898508238e33cf065.

For this release we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution for this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. As usual I'll hold off on pushing the release git tag until we have a few binaries built in case we encounter unexpected issues.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Using the ghc I built from the source tarball I encountered a problem in doing a cabal install -j5 hlint (on a Mac). I got cabal install -j5 hlint ... Failed to install extra-1.4.6 Build log ( /Users/gcolpitts/.cabal/logs/extra-1.4.6.log ): /Users/gcolpitts/.cabal/logs/extra-1.4.6.log: openFile: does not exist (No such file or directory) I didn't have this problem with earlier versions of ghc 8 when did cabal install hlint but I'm not sure if the versions involved in previous hlint components were the same Cheers George On Wed, May 11, 2016 at 2:03 PM Carter Schonwald wrote:

i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such file or directory whats that about? i can try to poke at it this evening too

On Wed, May 11, 2016 at 11:33 AM, Ben Gamari wrote:

...

...

[ Unknown signature status ] tl;dr: If you would like to produce a binary distribution for GHC 8.0.1 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to at long last announce the release of the 8.0.1 source distribution to binary packagers. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from GHC commit

e99c1e2516aeb283172c7e6898508238e33cf065.

For this release we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution for this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. As usual I'll hold off on pushing the release git tag until we have a few binaries built in case we encounter unexpected issues.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Which version of cabal the binary vs Cabal the lib etc did you use? Is this package level parallel builds or module level? I definitely hit a hard to reproduce problem where sublime Haskell would sometimes hang on stderr output from a vanilla cabal build invocation. What command let's you reproduce it intermittently? Also how many cores / ram does the machine have? On Wednesday, May 11, 2016, George Colpitts wrote:

seems to be intermittent, I have got past this problem

On Wed, May 11, 2016 at 9:12 PM George Colpitts javascript:_e(%7B%7D,'cvml','george.colpitts@gmail.com');> wrote:

...

Using the ghc I built from the source tarball I encountered a problem in doing a cabal install -j5 hlint (on a Mac). I got

cabal install -j5 hlint ... Failed to install extra-1.4.6 Build log ( /Users/gcolpitts/.cabal/logs/extra-1.4.6.log ): /Users/gcolpitts/.cabal/logs/extra-1.4.6.log: openFile: does not exist (No such file or directory)

I didn't have this problem with earlier versions of ghc 8 when did cabal install hlint but I'm not sure if the versions involved in previous hlint components were the same

Cheers George

On Wed, May 11, 2016 at 2:03 PM Carter Schonwald < carter.schonwald@gmail.com javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');> wrote:

...

i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such file or directory whats that about? i can try to poke at it this evening too

On Wed, May 11, 2016 at 11:33 AM, Ben Gamari javascript:_e(%7B%7D,'cvml','ben@well-typed.com');> wrote:

...

...

[ Unknown signature status ] tl;dr: If you would like to produce a binary distribution for GHC 8.0.1 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to at long last announce the release of the 8.0.1 source distribution to binary packagers. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from GHC commit

e99c1e2516aeb283172c7e6898508238e33cf065.

For this release we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution for this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. As usual I'll hold off on pushing the release git tag until we have a few binaries built in case we encounter unexpected issues.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org'); http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org'); http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On 12 May 2016 at 00:33, Ben Gamari wrote:

I am happy to at long last announce the release of the 8.0.1 source distribution to binary packagers.

I am going to build it in my Fedora Copr repo. One thing I noticed is that Cabal got reverted from version 1.24.1.0 in RC4 to 1.24.0.0? Is that intentional? (I managed to build cabal-install-1.24.0.0 with Cabal-1.24.1.0 but not 1.24.0.0 with RC4.) Thanks, Jens

On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote: [...]

I've pushed the result to the ghc-8.0 branch and have pushed a set of new source tarballs to the usual URL. The new release commit is

b594f8191273f4c913bc8413d30fd3061bb577c1

fyi, an easy way to verify you have the intended tarball is: $ tar xOf ghc-8.0.1-src.tar.xz ghc-8.0.1/GIT_COMMIT_ID; echo e99c1e2516aeb283172c7e6898508238e33cf065 (that's the old one) PS: I've just been told the md5sum of the new tarball is 94da3386c0de519eeea37586edd90187

Hi there, 2016-05-12 12:47 GMT+02:00 Ben Gamari :

Ben Gamari writes: Sorry about the false start earlier. It seems there were a few tricky bits in the integration between haddock and GHC's build system that weren't quite right. This should be fixed now.

I have tried to build the source tarball on FreeBSD, but it always stops somewhere around the documentation bits with the following error message: [..] make -C utils/haddock/doc html SPHINX_BUILD=/usr/local/bin/sphinx-build make: illegal option -- - usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] [-d flags] [-E variable] [-f makefile] [-I directory] [-j max_jobs] [-m directory] [-V variable] [variable=value] [target ...] utils/haddock/doc/ghc.mk:22: recipe for target 'html_utils/haddock/doc' failed gmake[1]: *** [html_utils/haddock/doc] Error 2 Makefile:129: recipe for target 'all' failed gmake: *** [all] Error 2 That is probably because FreeBSD has GNU make(1) as `gmake`, it should be invoked with that name. I suspect that, for some reason (which is unknown to me), the value of the $(MAKE) variable is not respected at the recursive invocation of make(1). Unfortunately, I will not have the time to figure this out today, so I am just reporting this without a proposal for the fix. Thanks, Gábor

2016-05-13 7:58 GMT+02:00 Páli Gábor János :

2016-05-13 7:55 GMT+02:00 Páli Gábor János :

...

That is probably because FreeBSD has GNU make(1) as `gmake`, it should be invoked with that name. I suspect that, for some reason (which is unknown to me), the value of the $(MAKE) variable is not respected at the recursive invocation of make(1). [..] Ohh, I was quick to surrender: all you have to do is to s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.

All right, everything is now filed as #12058.

On 05/14/16 11:28 AM, Ben Gamari wrote:

Páli Gábor János writes:

...

2016-05-13 7:58 GMT+02:00 Páli Gábor János :

...

2016-05-13 7:55 GMT+02:00 Páli Gábor János :

...

That is probably because FreeBSD has GNU make(1) as `gmake`, it should be invoked with that name. I suspect that, for some reason (which is unknown to me), the value of the $(MAKE) variable is not respected at the recursive invocation of make(1). [..] Ohh, I was quick to surrender: all you have to do is to s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.

All right, everything is now filed as #12058.

Thanks Páli! This should now be fixed on the ghc-8.0 branch. The question how is what should be done about for the 8.0.1 release. It seems that there are two decisions to be made here,

1. Do we cut a new source tarball and bump the tag? 2. If so, do we throw out the existing binary distributions?

The pragmatist in me wants to answer 1) yes, 2) no, although I do dislike the idea of distributing binaries that weren't derived from the associated source tarball.

This is interesting since I build dists for solaris and openbsd and none of those were affected by the bug. I guess all other Linuxes naturally use gnu make as `make' and Windows in msys too so only non-GNU/non-Linux systems should be affected and from those only FreeBSD has caught this. If this is true, then I would recommend "no" to both points and leave the fix in 8.0 branch for 8.0.2... or! you can create 8.0.1b sources and rebuild on FreeBSD to have 8.0.1b binary dist for this platform. Anyway I think nobody will shoot anyone if Gabor just fix it in his own tree and rebuild silently fixed 8.0.1. Cheers, Karel

On 05/14/16 10:18 PM, Páli Gábor János wrote:

2016-05-14 13:06 GMT+02:00 Karel Gardas :

...

On 05/14/16 11:28 AM, Ben Gamari wrote:

...

The pragmatist in me wants to answer 1) yes, 2) no, although I do dislike the idea of distributing binaries that weren't derived from the associated source tarball.

I guess all other Linuxes naturally use gnu make as `make' and Windows in msys too so only non-GNU/non-Linux systems should be affected and from those only FreeBSD has caught this.

Yes, that is possible. I do not know either Solaris or OpenBSD well enough, but I suspect they might have GNU make(1) installed in their paths as `make` or their default make(1) can understand GNU-style

No, on Solaris `make` is some Sun/Oracle make: $ make --version make: Warning: Ignoring DistributedMake -v option make: Warning: Ignoring DistributedMake -o option make: Fatal error: No dmake output dir argument after -o flag and GNU make is correctly installed as `gmake`: $ gmake --version GNU Make 3.82 Built for i386-pc-solaris2.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. and on OpenBSD this is the same, except that `make` is BSD make: $ make --version make: unknown option -- - usage: make [-BeiknpqrSst] [-C directory] [-D variable] [-d flags] [-f mk] [-I directory] [-j max_processes] [-m directory] [-V variable] [NAME=value] [target ...] $ gmake --version GNU Make 4.1 Built for x86_64-unknown-openbsd5.9 Copyright (C) 1988-2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Anyhow, in my humble opinion, it is a bad practice the hardwire the name of the make tool in the sources.

Completely agree with you on this.

...

If this is true, then I would recommend "no" to both points and leave the fix in 8.0 branch for 8.0.2...

Well, in theory, FreeBSD is still a Tier-1 platform, so every release should just build fine without any further efforts. I am also aware of the fact I am considered a minority here, and that this is just a minor technical problem that could wait for some undetermined time. However, personally, I would be quite disappointed if this promise was broken.

Hmm, indeed, FreeBSD is tier-1. I'm sorry, but I completely forgotten this.

I am sorry and apologize that I found this bug after the release was tagged, but I did not have the chance to test it before it was considered a final release. I tracked the 8.0.1 Release Candidates and provided binary tarballs for them, they all went fine, but apparently that was not enough.

Apparently this slipped from HEAD to 8.0 branch and it should not, especially considering this was already on RC4. But well such mistakes happen. OK! I've thought to save the energy on building another set of dists, but you have my word on this, to have FBSD folks happy I'm ready to rebuild again if Ben submits `c' version of 8.0.1 release source code. :-) Cheers, Karel

On 16 May 2016 at 19:27, Ben Gamari wrote: :

* the patch vendorising the alabaster theme for haddock's documentation

Thanks this also affects the build for RHEL7, so it will help me. Jens

I am getting a build error under openSUSE 11.4: make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build /usr/bin/sphinx-build -b html . .build-html Running Sphinx v1.2.3 loading translations [en]... done loading pickled environment... not yet created Theme error: no theme named 'alabaster' found (missing theme.conf?) make[2]: *** [html] Error 1 make[1]: *** [html_utils/haddock/doc] Error 2 make: *** [all] Error 2 Any suggestions how to fix it? Janek Dnia środa, 11 maja 2016, Ben Gamari napisał:

...

[ Unknown signature status ]

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today.

Hello GHC packagers,

I am happy to at long last announce the release of the 8.0.1 source distribution to binary packagers. You will find the usual artifacts at

http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from GHC commit

e99c1e2516aeb283172c7e6898508238e33cf065.

For this release we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution for this release.

Otherwise, let either Austin or I know if you have any trouble building your distribution. As usual I'll hold off on pushing the release git tag until we have a few binaries built in case we encounter unexpected issues.

Good luck and thanks for all of your work!

Cheers,

- Ben

[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

--- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

I did `pip install alabaster` but keep getting the same error. Unless I need to rebuild everything from scratch (in which case I'll probably disable the docs). Janek Dnia sobota, 14 maja 2016, Ben Gamari napisał:

Jan Stolarek writes:

...

I am getting a build error under openSUSE 11.4:

make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build /usr/bin/sphinx-build -b html . .build-html Running Sphinx v1.2.3 loading translations [en]... done loading pickled environment... not yet created

Theme error: no theme named 'alabaster' found (missing theme.conf?) make[2]: *** [html] Error 1 make[1]: *** [html_utils/haddock/doc] Error 2 make: *** [all] Error 2

Any suggestions how to fix it?

Yes, it seems that the theme that haddock requests was first introduced to Sphinx in version 1.3. I have encountered this issue myself as well and yesterday pushed a patch vendorizing the alabaster repository to ensure that we can build with earlier Sphinx versions. Without this patch the workaround is to `pip install alabaster` or disable building of Sphinx documentation.

So, be we yet again have the question of how to deal with this change. I really don't know what I want to let Haddock's documentation hold up the GHC release any more than it already has. As I indicated earlier, the prospect of releasing binaries which weren't derived from the official source release isn't terribly attractive but may be the best we can do here. The alternative would be do release 8.0.1 as-is with some notes in the release notes and immediately start preparing an 8.0.2 after its is released.

Thoughts?

Cheers,

- Ben

--- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

$ tar xOf ghc-8.2.0.20170404-src.tar.xz ghc-8.2.0.20170404/GIT_COMMIT_ID ; echo d67f0471cd3584c5a548ff30c9023b599b598d3e On Tue, Apr 4, 2017 at 9:01 AM Alan & Kim Zimmerman wrote:

There is no tag in the source tree, which commit has been used?

Alan

On 4 April 2017 at 06:21, Ben Gamari wrote:

tl;dr: If you would like to produce a binary distribution for GHC 8.2.1-rc1 then let me know, grab the source distribution and start building. The binary distributions will be announced one week from today.

Hello GHC packagers,

I am happy to announce the release of the 8.2.1-rc1 source distribution to binary packagers. You will find the usual source artifacts at

http://downloads.haskell.org/~ghc/8.2.1-rc1/

As usual, the sooner we can get the binary distributions together the better, but I will hold off on announcing the distributions until next Sunday to ensure we're all on the same page. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release.

Otherwise, let me know if you have any trouble building your distribution. I have yet to push the ghc-8.2.1-rc1 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone swimmingly save a few known issues (namely #13426, #13233, and #13509).

Good luck and thanks for all of your work!

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I don't know how to produce a binary distribution but I did do a build on Mac OS 10.12.4 with XCode 8.3. It went flawlessly and subjectively seemed much faster than previous builds. I then did a cabal install of hlint and verified that hlint worked. On Tue, Apr 4, 2017 at 1:22 AM Ben Gamari wrote:

tl;dr: If you would like to produce a binary distribution for GHC 8.2.1-rc1 then let me know, grab the source distribution and start building. The binary distributions will be announced one week from today.

Hello GHC packagers,

I am happy to announce the release of the 8.2.1-rc1 source distribution to binary packagers. You will find the usual source artifacts at

http://downloads.haskell.org/~ghc/8.2.1-rc1/

As usual, the sooner we can get the binary distributions together the better, but I will hold off on announcing the distributions until next Sunday to ensure we're all on the same page. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release.

Otherwise, let me know if you have any trouble building your distribution. I have yet to push the ghc-8.2.1-rc1 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone swimmingly save a few known issues (namely #13426, #13233, and #13509).

Good luck and thanks for all of your work!

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I'd like to run the testsuite on macOS but I am having trouble following the documentation at https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running Do I need to download something in addition to the source tarball or am I making some mistake? Following is what I tried: pwd /Users/gcolpitts/Downloads/ghc-8.2.0.20170404/libffi # doc says: The commands on this page can all be executed from the testsuite directory. bash-3.2$ find . -name testsuite ./libffi/build/testsuite ./libffi/build/x86_64-apple-darwin/testsuite bash-3.2$ pushd libffi/build/x86_64-apple-darwin/testsuite ~/Downloads/ghc-8.2.0.20170404/libffi/build/x86_64-apple-darwin/testsuite ~/Downloads/ghc-8.2.0.20170404 bash-3.2$ make test make: *** No rule to make target `test'. Stop. bash-3.2$ popd ~/Downloads/ghc-8.2.0.20170404 bash-3.2$ pushd libffi/build/testsuite ~/Downloads/ghc-8.2.0.20170404/libffi/build/testsuite ~/Downloads/ghc-8.2.0.20170404 bash-3.2$ make test make: *** No rule to make target `test'. Stop. bash-3.2$ popd ~/Downloads/ghc-8.2.0.20170404 bash-3.2$ make test /Applications/Xcode.app/Contents/Developer/usr/bin/make -C testsuite/tests CLEANUP=1 SUMMARY_FILE=../../testsuite_summary.txt make: *** testsuite/tests: No such file or directory. Stop. make: *** [test] Error 2 Thanks George On Wed, Apr 5, 2017 at 9:43 PM Jens Petersen wrote:

On 4 April 2017 at 13:21, Ben Gamari wrote:

I am happy to announce the release of the 8.2.1-rc1 source distribution to binary packagers.

It seems to build okay for me on Fedora 26 so far.

But the testsuite completely failed in timeout: see https://ghc.haskell.org/trac/ghc/ticket/13534

Cheers, Jens

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

tl;dr: If you would like to produce a binary distribution for GHC 8.2.1-rc2 then let me know, grab the source distribution and start building. The binary distributions will be announced one week from today. Hello GHC packagers, I am happy to announce the release of the 8.2.1-rc2 source distribution to binary packagers. You will find the usual source artifacts at http://downloads.haskell.org/~ghc/8.2.1-rc2/ As usual, the sooner we can get the binary distributions together the better, but I will hold off on announcing the distributions until next Sunday to ensure we're all on the same page. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let me know if you have any trouble building your distribution. I have yet to push the ghc-8.2.1-rc1 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone well. Note that in addition to the usual complement of Linux/Windows/Darwin bindists, I have also produced a FreeBSD distribution this time around. I've noticed that as my tools for producing these distributions improves the marginal cost of producing another distribution is shrinking. I would be happy to add OpenBSD as well, but first we'll need to nail #10032, as far as I understand. Good luck and thanks for all of your work! Cheers, - Ben