Haskell Stack Ports on Apple Silicon

[Steven Smith]

stack (and ghc, cabal) can only build x86_64, so it’s an x86_64 binary that runs on the M1 (whether built on x86_64 or arm64).

The problem is that with the current supported_archs setting in stack, you hit this architecture mismatch error when trying to install pandoc on the M1:

> Cannot install pandoc for the arch 'arm64' because
> It’s dependency stack is only installed for the arch 'x86_64'
> and does not have a universal variant.
> Unable to execute port: architecture mismatch

This looks like a bug in MacPorts’s download and/or build logic, at least for installing x86_64 binaries on an M1 box.


> On Aug 14, 2021, at 7:26 PM, Joshua Root <jmr at macports.org> wrote:
> 
> On 2021-8-15 05:43 , Ken Cunningham wrote:
>> You could override it, in pandoc or in the PortGroup:
>> depends_skip_archcheck-append stack
> 
> What architecture is the pandoc binary you end up with though? It seems unlikely that an x86_64 stack would generate an arm64 binary, and if it generates an x86_64 binary, calling it arm64 is wrong.
> 
> The situation with arm64 and x86_64 is almost the same as x86_64 and i386 on earlier systems. Suppose port A depends on port B and B sets a supported_archs that doesn't include $new_arch. If A uses B in such a way that its architecture matters, like if A's executable links with B's library, then A usually needs to set the same supported_archs as B. This is because you can't mix archs in an executable. (Yes, universal binaries exist, but only the slice for one architecture can actually be loaded into a given process.)
> 
> - Josh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3898 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210814/181a99a1/attachment.bin>