monomer
monomer copied to clipboard
fjvallarino
install failure on mac m1
Found this project via https://www.reddit.com/r/haskell/comments/p12pjs/ann_monomer_a_gui_library_for_haskell. Thank you very much!
Installing went well up to this point:
06:27:37 ~/src/GUI/monomer-starter$ stack build
...
monomer > configure
monomer > Configuring monomer-1.0.0.0...
monomer > build
monomer > Preprocessing library for monomer-1.0.0.0..
monomer > Building library for monomer-1.0.0.0..
monomer > [ 1 of 102] Compiling Monomer.Common.BasicTypes
monomer > [ 2 of 102] Compiling Monomer.Common
monomer > [ 3 of 102] Compiling Monomer.Common.Lens
monomer > <command line>: dlopen(/opt/homebrew/lib/libSDL2.dylib, 5): no suitable image found. Did find:
monomer > /opt/homebrew/lib/libSDL2.dylib: mach-o, but wrong architecture
monomer > /opt/homebrew/Cellar/sdl2/2.0.14_1/lib/libSDL2-2.0.0.dylib: mach-o, but wrong architecture
Progress 1/2
-- While building package monomer-1.0.0.0 (scroll up to its section to see the error) using:
/Users/simon/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 --builddir=.stack-work/dist/x86_64-osx/Cabal-3.2.1.0 build --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Not sure if it's an artifact of my machine, or a general problem for all mac m1 users.
06:27:49 ~/src/GUI/monomer-starter$ brew install sdl2
Warning: sdl2 2.0.14_1 is already installed and up-to-date.
To reinstall 2.0.14_1, run:
brew reinstall sdl2
06:31:46 ~/src/GUI/monomer-starter$ brew list sdl2
brew list sdl2
/opt/homebrew/Cellar/sdl2/2.0.14_1/bin/sdl2-config
/opt/homebrew/Cellar/sdl2/2.0.14_1/include/SDL2/ (76 files)
/opt/homebrew/Cellar/sdl2/2.0.14_1/lib/libSDL2-2.0.0.dylib
/opt/homebrew/Cellar/sdl2/2.0.14_1/lib/cmake/ (2 files)
/opt/homebrew/Cellar/sdl2/2.0.14_1/lib/pkgconfig/sdl2.pc
/opt/homebrew/Cellar/sdl2/2.0.14_1/lib/ (4 other files)
/opt/homebrew/Cellar/sdl2/2.0.14_1/share/aclocal/sdl2.m4
06:32:02 ~/src/GUI/monomer-starter$ file /opt/homebrew/Cellar/sdl2/2.0.14_1/lib/libSDL2-2.0.0.dylib
/opt/homebrew/Cellar/sdl2/2.0.14_1/lib/libSDL2-2.0.0.dylib: Mach-O 64-bit dynamically linked shared library arm64
Hi @simonmichael!
It looks like an issue with the architecture. I tested on an x86 Macbook Pro, but I have not been able to try it on an M1 so far.
I'll take a look if I can figure something out, but unfortunately I can't test it myself for the moment.
Notes from #ghc:
stack is trying to build an x86_64 executable, as it should because this GHC (8.10.4) doesn't build arm64 ones yet. For this to succeed it would need an x86_64 version of the SDL lib. I'm not sure how hard that is right now.
GHC 8.10.5 (and GHC 9.2 prereleases, and perhaps the next release of 9.0) can build arm64 executables, with -fllvm. So that might also work.
As soon as Stackage publishes a new version using GHC 8.10.5 (the latest 8.x branch in Stackage is 8.10.4), I'll push a branch with revised version bounds. There is a nightly with 9.0.1 too. If you, or somebody with an M1 can try it, it would be great!
I plan on getting an M1 when the new ones are released, but I don't know when that is going to happen (so, unfortunately, I'm not an option for testing this until that time).
8.10.6 was just released which should support M1 better, and fix the RTS symbol regression in 8.10.5.
I just pushed to GitHub (not Hackage) updated versions of the library and monomer-starter, pointing to the Stackage lts-18.7 version that includes GHC 8.10.6 (which, in turn, has improved M1 support).
I'm not sure if Stack supports M1 currently, but both projects now are buildable with cabal using cabal v2-build after the release of nanovg-0.8.0.0 to Hackage (and the addition of the corresponding cabal.project files).
Nice, but I can't report any improvement on M1 yet. Maybe I didn't do it right, or maybe it's just a case of wait for the native code generator in 9.2.
$ stack build --ghc-options='-fllvm'
monomer > configure
monomer > Configuring monomer-1.0.0.2...
monomer > build
monomer > Preprocessing library for monomer-1.0.0.2..
monomer > Building library for monomer-1.0.0.2..
monomer > [ 1 of 102] Compiling Monomer.Common.BasicTypes
monomer > [ 2 of 102] Compiling Monomer.Common
monomer > [ 3 of 102] Compiling Monomer.Common.Lens
monomer > <command line>: dlopen(/opt/homebrew/lib/libSDL2.dylib, 5): no suitable image found. Did find:
monomer > /opt/homebrew/lib/libSDL2.dylib: mach-o, but wrong architecture
monomer > /opt/homebrew/Cellar/sdl2/2.0.14_1/lib/libSDL2-2.0.0.dylib: mach-o, but wrong architecture
Progress 1/2
-- While building package monomer-1.0.0.2 (scroll up to its section to see the error) using:
/Users/simon/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.6 --builddir=.stack-work/dist/x86_64-osx/Cabal-3.2.1.0 build --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
That's bad. I guess we'll have to wait a bit more for the native code generator, as you mention. Thanks!
Can you try with nix ? The following command builds fine with 8.10.6 on macos 10.15 (I haven't tried with M1 though)
nix run github:smunix/monomer/macosx.gh-actions#tutorial
I can successfully compile the example with x86-64 Homebrew's llvm, sdl2 and glew packages on M1.
Environment:
eval "$(arch -x86_64 /usr/local/bin/brew shellenv)"
# LLVM!
# To use the bundled libc++ please add the following LDFLAGS:
export LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib $LDFLAGS"
# llvm is keg-only, which means it was not symlinked into /usr/local,
# because macOS already provides this software and installing another version in
# parallel can cause all kinds of trouble.
# If you need to have llvm first in your PATH, run:
export PATH="/usr/local/opt/llvm/bin:$PATH"
# For compilers to find llvm you may need to set:
export LDFLAGS="-L/usr/local/opt/llvm/lib $LDFLAGS"
export CPPFLAGS="-I/usr/local/opt/llvm/include $CPPFLAGS"
export PATH="/usr/local/opt/openssl/bin:$PATH"
and just open a Rosetta shell and run stack run
@natsukagami nice! I think this is a great solution until 9.2 is released with the native code generator; I'll add this to the Setup page.
I will keep the issue open until 9.2, which hopefully will make the process more straightforward.
Thanks!
@juhp I'm not sure since I don't have an M1 to test. @simonmichael reported 8.10.6 did not work for him, and I don't expect differences between those versions.
No need for further work on this, I'm just confirming that
- no, ghc-8.10.7 doesn't make a difference.
- I could not reproduce @natsukagami's success from those instructions.
Wanted to mention that you should not have the equivalent LDFLAGS provided by the aarch64 LLVM inside the x86-64 shell. I am not sure how the MacOS linker works, but if it finds the aarch64 dylib first it will just fail instead of keep looking for the x86-64 dylib.
Hi guys,
Just to let you know, I have been able to compile and run the starter project using GHC 8.10.7 on an M1. I used Cabal for building, had LLVM installed with Homebrew and prepended this to PATH: $(brew --prefix)/opt/llvm/bin, I don't think I did anything else, but it seems to run without issues. I'll hack some more for a toy project and will let you know if I find any problem.
This is the console output I get when I do a cabal run, besides the GUI itself opening of course 😄:
Renderer: Apple M1
Version: 4.1 Metal - 76.3
Regards
@DavSanchez hi! That's great to hear! Does it work on the M1 architecture or is it using Rosetta?
Hi @fjvallarino, yes, it's M1 native. The Monomer starter app (called only app) shows in Activity Monitor as being of Kind Apple (if using Rosetta, it would say Intel)
My GHC 8.10.7 was installed using ghcup, which downloaded from https://downloads.haskell.org/~ghc/8.10.7/ghc-8.10.7-aarch64-apple-darwin.tar.xz (also linked here) and using ghc -v mentions loading an environment from ~/.ghc/aarch64-darwin-8.10.7/.... Not sure if I can confirm this further by inspecting the binary or something, probably yes, but I don't know how.
Best regards, David
Nice! That's awesome. I'll keep the issue open for a bit more just in case other users want to share their experience.
Thanks for reporting!
Hey @DavSanchez. I'm trying to reproduce your setup but things are not going smoothly as in your case. I'm trying to build monomer-starter app with cabal as you did it, but my compilation gets stuck every time on OpenGLRaw-3.3.4.1
For some reason It randomly reports that it cannot execute opt (although it's available and used to compile previous files). Do you know what can be the case here?
Hi @DrearyLisper , I'm not sure and I'm currently away from home, but I'll try to check later.
For reference, this is the setup that is currently working for me both in Intel and M1: https://github.com/DavSanchez/hematria Note the cabal.project file at the root which references the GUI package and places a constraint on nanovg and the cabal file inside hematria-gui which defines the executable I have successfully run with cabal run hematria-gui.
Also make sure you have llvm prepended to your PATH as I commented earlier and also that you have installed both sdl2 and glew with Homebrew.
Hey @DavSanchez. Could you share which version of llvm you use? I currently have llvm@12 installed.
Update from me, with a different toolchain (now it's all arm binaries installed by ghcup) and OS (now it's macos monterrey). LLVM 13 comes with macos, and is installed a second time with brew if that matters. I also updated the stack.yaml from lts-18.6 to lts-18.18.
stack build (using ghc 8.10.7) completes successfully, with just this final warning:
...
monomer > Installing executable generative in /Users/simon/.stack/snapshots/aarch64-osx/defecca5bd7beb1e174cec474a367750514baa131ef8216eb5522d51dc0d6c37/8.10.7/bin
monomer > Registering library for monomer-1.2.0.0..
Building all executables for `monomer-starter' once. After a successful build of all of them, only specified executables will be rebuilt.
monomer-starter > configure (exe)
Configuring monomer-starter-0.1.0.0...
monomer-starter > build (exe)
Preprocessing executable 'app' for monomer-starter-0.1.0.0..
Building executable 'app' for monomer-starter-0.1.0.0..
[1 of 2] Compiling Main
<no location info>: warning: [-Wmissed-extra-shared-lib]
dlopen(libGLEW.dylib, 0x0005): tried: '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/rts/libGLEW.dylib' (no such file), '/System/Library/Frameworks/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../haskeline-0.8.2/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../ghc-8.10.7/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../terminfo-0.4.1.4/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../process-1.6.13.2/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../hpc-0.6.1.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../ghci-8.10.7/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../ghc-heap-8.10.7/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../ghc-boot-8.10.7/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../exceptions-0.10.4/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../template-haskell-2.16.0.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../pretty-1.1.3.6/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../ghc-boot-th-8.10.7/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../stm-2.5.0.1/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../mtl-2.2.2/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../transformers-0.5.6.2/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../directory-1.3.6.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../unix-2.7.2.2/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../time-1.9.3/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../filepath-1.4.2.1/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../binary-0.8.8.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../containers-0.6.5.1/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../bytestring-0.10.12.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../deepseq-1.4.4.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../array-0.5.4.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../base-4.14.3.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../integer-gmp-1.0.3.0/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../ghc-prim-0.6.1/libGLEW.dylib' (no such file), '/Users/simon/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bin/../rts/libGLEW.dylib' (no such file), '/System/Library/Frameworks/libGLEW.dylib' (no such file), 'libGLEW.dylib' (no such file), '/usr/local/lib/libGLEW.dylib' (no such file), '/usr/lib/libGLEW.dylib' (no such file), '/Users/simon/src/GUI/monomer-starter/libGLEW.dylib' (no such file), '/usr/local/lib/libGLEW.dylib' (no such file), '/usr/lib/libGLEW.dylib' (no such file)
It's OK if you don't want to use symbols from it directly.
(the package DLL is loaded by the system linker
which manages dependencies by itself).
[2 of 2] Compiling Paths_monomer_starter
Linking .stack-work/dist/aarch64-osx/Cabal-3.2.1.0/build/app/app ...
monomer-starter > copy/register
Installing executable app in /Users/simon/src/GUI/monomer-starter/.stack-work/install/aarch64-osx/defecca5bd7beb1e174cec474a367750514baa131ef8216eb5522d51dc0d6c37/8.10.7/bin
Completed 120 action(s).
stack run app ran the counter app successfully. 🎉
@DrearyLisper latest version, it's 13 from Homebrew.
@simonmichael great to hear it's working with stack as well! I had switched to cabal because apparently stack was not using GHC for aarch64 yet (for me it was always downloading for x86-64). I'll check again. Could you add monomer as a dependency without issues? I see it's not on Stackage LTS 18.18.
Edit: I confirm from my side it works on M1 with stack (had to download it again with ghcup, I was using an older x86-64 version of stack running with Rosetta!), selecting lts-18.19 (GHC 8.10.7) as resolver and setting both monomer and nanovg in extra-deps. Something like:
resolver: lts-18.19
packages: .
extra-deps:
- monomer-1.2.0.0
- nanovg-0.8.0.0
Would suffice.
@DavSanchez exactly, the mixed binaries cause lots of trouble, arm mac owners beware. More notes about it on reddit.
Hello @fjvallarino, I just came across your project - marvelous! I'm hoping to use it to build a desktop version of https://scripta.io, the main feature of which is real-time editing of LaTeX documents - instantaneous (ha ha!, but pretty close) rendering of LaTeX to Html. Scripta.io is written in Elm. Alas, I'll have to wait for GHC 9.2, I guess -- I only have an M1 mac.
Anyhow, Monomer looks really, really nice, and I can't wait to use it.
Ah, Just saw @DavSanchez 's post above. I tried the indicated configuration, but got the errors listed below. I am running MacOS 12.5:
➜ monomer-exp git:(main) ✗ stack build
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
configure: error: in `/Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7.temp/ghc-8.10.7':
configure: error: C compiler cannot create executables
See `config.log' for more details
Received ExitFailure 77 when running
Raw command: /Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7.temp/ghc-8.10.7/configure --prefix=/Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7/
Run from: /Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7.temp/ghc-8.10.7/
Error: Error encountered while configuring GHC with
/Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7.temp/ghc-8.10.7/configure --prefix=/Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7/
run in /Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7.temp/ghc-8.10.7/
The following directories may now contain files, but won't be used by stack:
- /Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7.temp/
- /Users/carlson/.stack/programs/x86_64-osx/ghc-8.10.7/
For more information consider rerunning with --verbose flag
Configuring GHC ...
Could the below be the problem?
➜ monomer-exp git:(main) ✗ clang --version
Homebrew clang version 14.0.6
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
Not sure if this will work, but given that LLVM seems to be already in your PATH, have you tried setting up LDFLAGS and CPPFLAGS as the LLVM package for Homebrew suggests? I'll try to compile it again when I get back from work.
export LDFLAGS="-L/opt/homebrew/opt/llvm/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm/include"
I tried the exports you mentioned, but the result was the same. Regarding target, as in the below, should it perhaps be x86?
➜ monomer-exp git:(main) ✗ gcc --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin