stack @2.5.1_0 build fails on Big Sur 11.1 Beta / Xcode 12.3 Beta

[rswail (Ron Wail)]

Build fails with:

  :info:build [ 40 of 109] Compiling Stack.Constants
  :info:build <command line>: can't load framework: Cocoa (not found)
  :info:build Completed 160 action(s).
  :info:build --  While building package stack-2.3.3 using:
  :info:build       /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_por  ts_lang_stack/stack/work/stack-2.3.3/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup/setup --builddir=.stack-work/dist/x86_64-os  x/Cabal-2.4.0.1 build lib:stack exe:stack --ghc-options ""
  :info:build     Process exited with code: ExitFailure 1
  :info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_relea  se_tarballs_ports_lang_stack/stack/work/stack-2.3.3" && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macp  orts.org_macports_release_tarballs_ports_lang_stack/stack/work/bin/stack build --with-gcc /usr/bin/clang --allow-different-user
  :info:build Exit code: 1

[Tatsh (Andrew Udvare)]

For me this affects shellcheck and pandoc.

[amake (Aaron Madlon-Kay)]

Looks related to this: ​https://gitlab.haskell.org/ghc/ghc/-/issues/18446

[Tatsh (Andrew Udvare)]

build log

[rswail (Ron Wail)]

Same problem still occurs in stack-2.5.1

[rswail (Ron Wail)]

Updated ticket title for latest version of stack/Big Sur/Xcode. Problem is the same, unable to find Cocoa when compiling.

[kencu (Ken)]

This is fixed upstream, and there are patches upstream in the noted upstream issue.

[Tatsh (Andrew Udvare)]

Last I checked there's patches but nothing merged yet. Do you have a link to a commit?

[kencu (Ken)]

just what's in that issue. But the point is it looks like we can stop posting logs and twisting about what's wrong and how to fix it, and work on implementing the fixes if possible...the way stack works, we may have to just wait for upstream to release a new version with the fixes in it. Next step would surely be to get them to commit the patches if they feel they are the right fixes. Then make a new release.

I have patched and built stack from source before, but integrating a patched custom stack into MP is hard.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #61548.

[ryandesign (Ryan Carsten Schmidt)]

It looks like the fixes were merged to ghc master and the 8.10 and 8.8 branches a week ago.

[jfb007]

I'm on macOS 11.1 and have the same problems, compiling pandoc: it get's stuck at compiling stack. I tried to install stack from source; to no avail. Is there any alternative way to install pandoc on macOS 11.1? Thanks

[kencu (Ken)]

if you're desperate right now, download the latest system's pandoc for x86_64 from the macports packages website, throw the binary in your PATH somewhere, and comment out the dep in the port you're trying to install. Your binary will be found.

30 seconds, max.

but don't post up any tickets about this...

[jungx098]

Replying to jfb007:

I'm on macOS 11.1 and have the same problems, compiling pandoc: it get's stuck at compiling stack. I tried to install stack from source; to no avail. Is there any alternative way to install pandoc on macOS 11.1? Thanks

The stack prebuilt is available in the meantime, I guess.

I have installed pandoc with the following:

$ sudo port install stack +prebuilt
$ sudo port install pandoc

[Tatsh (Andrew Udvare)]

How about removing the Stack dependency altogether for Pandoc and Shellcheck?

[kencu (Ken)]

Replying to Tatsh:

How about removing the Stack dependency altogether for Pandoc and Shellcheck?

I think you need stack to be a build dep for pandoc... how else are you going to build it?

[catap (Kirill A. Korinsky)]

Replying to kencu:

Replying to Tatsh:

How about removing the Stack dependency altogether for Pandoc and Shellcheck?

I think you need stack to be a build dep for pandoc... how else are you going to build it?

I know to possible way to install a pandoc:

1) Install via installer from website: ​https://pandoc.org/installing.html

2) To use this hack: ​https://github.com/yairchu/macos11-haskell-workaround

[kencu (Ken)]

neither of those suggestions would allow pandoc to build without stack, of course, so removing the stack dependancy from the pandoc build script still won't work.

But the first looks like an alternate method to get a working pandoc for now. Downloading MacPort's last Intel version as I suggested from here <​http://packages.macports.org/pandoc/pandoc-2.10.1_0.darwin_19.x86_64.tbz2> also is a workaround to get a copy.

The second looks like a cool hack! But it looks like the ghc fixes for BigSur are in the release pipeline, so should be soonish.

[kencu (Ken)]

the fix referenced for ghc on BigSur was supposed to be in 8.10.3, and I notice we have that version of ghc now:

​https://github.com/macports/macports-ports/commit/1dd4dc03a88ddc0bf7cf6862692a52ceb524ee8d#diff-c7968cfa7dd4491c4f36b05d17922247eee14b20e9a0abd8e2a05879af62c173

[catap (Kirill A. Korinsky)]

Replying to kencu:

the fix referenced for ghc on BigSur was supposed to be in 8.10.3, and I notice we have that version of ghc now:

​https://github.com/macports/macports-ports/commit/1dd4dc03a88ddc0bf7cf6862692a52ceb524ee8d#diff-c7968cfa7dd4491c4f36b05d17922247eee14b20e9a0abd8e2a05879af62c173

but pandoc is required stack or cabal to be built.

And current version of cabal-3.0.0 can't be use with GHC-8.10.

You can follow this issue ​https://github.com/haskell/cabal/issues/6698 and see that until 3.4.0 is released it can't be updated inside ports.

So, here two options:

• wait until cabal-3.4.0 is released and update pandoc port (and a lot of dependencies),
• wait until the next version of stack with GHC with fix is released (and doesn't do anything).

[kencu (Ken)]

yes, true, we are now waiting for stack and cabal to be updated.

So your BigSur pandoc option right now is to download a premade pandoc binary from somewhere, ie the two places we have already listed.

But deleting stack from the pandoc build script will get us nowhere at all.

[Tatsh (Andrew Udvare)]

Replying to kencu:

Replying to Tatsh:

How about removing the Stack dependency altogether for Pandoc and Shellcheck?

I think you need stack to be a build dep for pandoc... how else are you going to build it?

Cabal: ​https://github.com/gentoo/gentoo/blob/master/app-text/pandoc/pandoc-2.9.2.1.ebuild. Gentoo has a Cabal eclass (equivalent of a PortGroup). Ebuilds for compatible Haskell packages are generated using ​https://github.com/gentoo-haskell/hackport

Also I must point out that unlike most other packages, Stack performs downloading during a non-fetch phase IIRC. This is a concern for those wanting to do a fully offline installation given the appropriate distfiles.

[kencu (Ken)]

Until such time as ghc/cabal/stack are fixed properly to work on BIgSur Intel and arm64, see <​https://github.com/macports/macports-ports/pull/9537> for a workaround that installs a working binary on those systems (the arm64 version runs the Intel binary under Rosetta2).

[kencu (Ken)]

Replying to Tatsh:

Cabal: ​https://github.com/gentoo/gentoo/blob/master/app-text/pandoc/pandoc-2.9.2.1.ebuild. Gentoo has a Cabal eclass (equivalent of a PortGroup). Ebuilds for compatible Haskell packages are generated using ​https://github.com/gentoo-haskell/hackport

As far as I can see, that build file uses cabal (and therefore stack) to build pandoc.

<​https://github.com/gentoo/gentoo/blob/75f59be946abf7424e555754debfcd9da824f6fa/app-text/pandoc/pandoc-2.9.2.1.ebuild#L82>

Also I must point out that unlike most other packages, Stack performs downloading during a non-fetch phase IIRC. This is a concern for those wanting to do a fully offline installation given the appropriate distfiles.

That's true. We just haven't yet got to the point where we are prepared to pound on poor Steve about implementing all that ghc / stack / cabal dependency downloading in MacPorts. It's a big project to do, as that gentoo build file demonstrates.

I'm sure he'd love some help with that project, if you are motivated. Ryan has asked many times for a volunteer to step up and do all that work -- it won't be me, however.

[kencu (Ken)]

Oh, Andrew -- if you are saying that the current pandoc Portfile should be modified to use only cabal-install and not stack to build pandoc -- yes, I suppose it could be, if we took over the dependency issues from stack in the Portfile.

<​https://stackoverflow.com/questions/30913145/what-is-the-difference-between-cabal-and-stack>

that would be a change in the way the ghc ports are currently being managed on MacPorts.

[ken-cunningham-webuse]

In 39f5b1344934fd8777143d548c2fb04ef4affec6/macports-ports (master):

pandoc: install binary for BigSur

this port installs the x86_64 binary from
Catalina on BigSur Intel and arm64

ghc/stack/cabal will work on BigSur Intel
at some point. Just when they might work on arm64
is less clear.

see: #61422

[Tatsh (Andrew Udvare)]

Replying to kencu:

Replying to Tatsh:

Cabal: ​https://github.com/gentoo/gentoo/blob/master/app-text/pandoc/pandoc-2.9.2.1.ebuild. Gentoo has a Cabal eclass (equivalent of a PortGroup). Ebuilds for compatible Haskell packages are generated using ​https://github.com/gentoo-haskell/hackport

As far as I can see, that build file uses cabal (and therefore stack) to build pandoc.

<​https://github.com/gentoo/gentoo/blob/75f59be946abf7424e555754debfcd9da824f6fa/app-text/pandoc/pandoc-2.9.2.1.ebuild#L82>

Also I must point out that unlike most other packages, Stack performs downloading during a non-fetch phase IIRC. This is a concern for those wanting to do a fully offline installation given the appropriate distfiles.

That's true. We just haven't yet got to the point where we are prepared to pound on poor Steve about implementing all that ghc / stack / cabal dependency downloading in MacPorts. It's a big project to do, as that gentoo build file demonstrates.

I'm sure he'd love some help with that project, if you are motivated. Ryan has asked many times for a volunteer to step up and do all that work -- it won't be me, however.

I can't be the one really either. I only use Pandoc and Shellcheck (and rarely for both) and I don't really know Haskell well enough to deal with its packaging. If MacPorts went binary-only for both of these packages I would accept that.

[Tatsh (Andrew Udvare)]

In 9cc2e7c6b9428a4777bbc04a21bab7c5a3deccde/macports-ports (master):

shellcheck: install binary for BigSur

this port installs the x86_64 binary on Intel and
arm64

ghc/stack/cabal will work on BigSur Intel
at some point. Just when they might work on arm64
is less clear.

see: #61422

[essandess (Steve Smith)]

Please see ​https://github.com/macports/macports-ports/pull/10086

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #62579.

[essandess (Steve Smith)]

Please see ​https://github.com/macports/macports-ports/pull/10514

I moved pandoc to PG haskell_cabal.

The recent update of cabal works very well, and I suspect that it will work with many cabal/stack projects within MacPorts.

[essandess (Steve Smith)]

In 05945e4f88d59a8a2a1bc460fa27b63721cd5f04/macports-ports (master):

stack: Update to version rc/v2.7.0.1

Related:

• #61422
• commercialhaskell/stackhttps://github.com/macports/macports-ports/pull/5456
• commercialhaskell/stackhttps://github.com/macports/macports-ports/pull/5491
• ​https://github.com/macports/macports-ports/pull/10086

[kencu (Ken)]

fixed by changes to the stack port over the past few years