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 <j...@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
smime.p7s
Description: S/MIME cryptographic signature
