Building on M1/arm64 macOS – "not a string" errors (and other misc. notes)

[frozenpandaman]

Hi! Thanks so much for this great fork of Aegisub with all these fantastic features and bugfixes.

I'm trying to use a number of scripts that rely on Yutils, but the problem there is it loads up my local fontconfig and pangocairo libraries, are compiled for my machine's architecture – but the latest provided release of Aegisub is for & expects x86_64, not arm64. So, I need to build it myself, since a binary for newer Apple silicon Macs is not provided. (Happy to provide you with one if you want, once this is fixed!)

---

In following the "compilation" section of the readme, I ran into an issue during the build step that ended with ninja: build stopped: subcommand failed. It seemed the cause was this:

[1256/1374] Compiling C++ object aegisub.p/src_dialog_colorpicker.cpp.o
FAILED: aegisub.p/src_dialog_colorpicker.cpp.o 
c++ -Iaegisub.p -I. -I.. -I../libaegisub/include -Isrc/libresrc -I../src/libresrc -Isrc -I../src -Isubprojects/icu/source/common -I../subprojects/icu/source/common -Isubprojects/icu/source/i18n -I../subprojects/icu/source/i18n -Isubprojects/hunspell-1.7.0/src -I../subprojects/hunspell-1.7.0/src -Isubprojects/luajit/src -I../subprojects/luajit/src -I/opt/homebrew/Cellar/libass/0.17.1/include -I/opt/homebrew/Cellar/libunibreak/5.1/include -I/opt/homebrew/Cellar/harfbuzz/7.1.0/include/harfbuzz -I/opt/homebrew/Cellar/glib/2.76.1/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.76.1/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.42/include -I/opt/homebrew/Cellar/graphite2/1.3.14/include -I/opt/homebrew/Cellar/fribidi/1.0.12/include/fribidi -I/opt/homebrew/opt/freetype/include/freetype2 -I/opt/homebrew/Cellar/libpng/1.6.39/include/libpng16 -I/opt/homebrew/Cellar/boost/1.81.0_1/include -I/opt/homebrew/lib/wx/include/osx_cocoa-unicode-3.2 -I/opt/homebrew/include/wx-3.2 -I/opt/homebrew/Cellar/ffms2/2.40_3/include -I/opt/homebrew/Cellar/ffmpeg/5.1.2_6/include -I/opt/homebrew/Cellar/fftw/3.3.10_1/include -I/opt/homebrew/Cellar/uchardet/0.0.8/include/uchardet -fcolor-diagnostics -include-pch aegisub.p/agi_pre.h.pch -Wall -Winvalid-pch -std=c++14 -O3 -DNDEBUG -DGL_SILENCE_DEPRECATION -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_USE_DLL=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -MD -MQ aegisub.p/src_dialog_colorpicker.cpp.o -MF aegisub.p/src_dialog_colorpicker.cpp.o.d -o aegisub.p/src_dialog_colorpicker.cpp.o -c ../src/dialog_colorpicker.cpp
../src/dialog_colorpicker.cpp:413:2: error: unknown type name 'NSUInteger'
        NSUInteger width = CGImageGetWidth(img);
        ^
../src/dialog_colorpicker.cpp:414:2: error: unknown type name 'NSUInteger'
        NSUInteger height = CGImageGetHeight(img);
        ^
2 errors generated.

I'm sure this isn't an ideal fix – please let me know what I should be doing, or if this is a fix you could make to the codebase – but by changing these two NSUInteger declarations to unsigned int within src/dialog_colorpicker.cpp makes the ninja build work!!

This generates an aegisub file in the build/ directory, as the readme says. Clicking on it launches Terminal, which then indeed launches the application/GUI… however, no scripts are able to load. The application starts with this error after it scans the autoload/ directory:

Also seen in the Automation Manager window:

---

If I follow the OS X instructions under "Building Aegisub" instead (I don't really see how these two differ… since it also builds with ninja when you compile, no?) with some changes to the exports for M1 architecture (documented by myself years ago at that link) I get the following error in the meson compile -C build step:

[477/486] Compiling C++ object aegisub.p/src_spellchecker_hunspell.cpp.o
FAILED: aegisub.p/src_spellchecker_hunspell.cpp.o 
c++ -Iaegisub.p -I. -I.. -I../libaegisub/include -Isrc/libresrc -I../src/libresrc -Isrc -I../src -Isubprojects/boost_1_74_0 -I../subprojects/boost_1_74_0 -Isubprojects/luajit/src -I../subprojects/luajit/src -I/opt/homebrew/Cellar/libass/0.17.1/include -I/opt/homebrew/Cellar/libunibreak/5.1/include -I/opt/homebrew/Cellar/harfbuzz/7.1.0/include/harfbuzz -I/opt/homebrew/Cellar/glib/2.76.1/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.76.1/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.42/include -I/opt/homebrew/Cellar/graphite2/1.3.14/include -I/opt/homebrew/Cellar/fribidi/1.0.12/include/fribidi -I/opt/homebrew/opt/freetype/include/freetype2 -I/opt/homebrew/Cellar/libpng/1.6.39/include/libpng16 -I/opt/homebrew/lib/wx/include/osx_cocoa-unicode-3.2 -I/opt/homebrew/include/wx-3.2 -I/opt/homebrew/Cellar/icu4c/72.1/include -I/opt/homebrew/Cellar/ffms2/2.40_4/include -I/opt/homebrew/Cellar/ffmpeg/6.0/include -I/opt/homebrew/Cellar/fftw/3.3.10_1/include -I/opt/homebrew/Cellar/hunspell/1.7.2/include/hunspell -I/opt/homebrew/Cellar/uchardet/0.0.8/include/uchardet -I/opt/homebrew/opt/icu4c/include -fcolor-diagnostics -include-pch aegisub.p/agi_pre.h.pch -Wall -Winvalid-pch -std=c++14 -O2 -g -D_DEBUG -DGL_SILENCE_DEPRECATION -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -MD -MQ aegisub.p/src_spellchecker_hunspell.cpp.o -MF aegisub.p/src_spellchecker_hunspell.cpp.o.d -o aegisub.p/src_spellchecker_hunspell.cpp.o -c ../src/spellchecker_hunspell.cpp
../src/spellchecker_hunspell.cpp:33:10: fatal error: 'hunspell/hunspell.hxx' file not found
#include <hunspell/hunspell.hxx>
         ^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
[478/486] Compiling C++ object aegisub.p/src_audio_player_openal.cpp.o
   (lots of warnings about deprecations here)
[485/486] Compiling C++ object aegisub.p/src_visual_tool.cpp.o
ninja: build stopped: subcommand failed.

This "'hunspell/hunspell.hxx' file not found" error was something I & others also ran into years ago: TypesettingTools#145

If I change the line #include <hunspell/hunspell.hxx> to say #include <hunspell.hxx> instead, though, the error goes away and the build succeeds! ([486/486] Linking target aegisub, yay!)

But clicking on this resultant file, like above, gives me all the same "not a string" messages when loading my scripts. (And when compiled into an .app using meson compile osx-bundle & all the relevant commands, the application simply crashes upon trying to run it.)

---

Any fixes or suggestions for achieving a build here? I'm just trying to get a working version of the .app for personal use – and feel like I'm so close to getting it working! Thanks.

[ayypril]

Are you still running into these issues? For what it's worth, I was able to build the binary and get it to work without errors on an M1.

I installed the same dependencies as specified in the CI yml, except I built hunspell and libwebp from source (and hunspell from source seems to fix the header file path issues, so changing that isn't required).

I replaced the instances of NSUInteger with size_t since that's what those functions appear to return and ran the same setup commands the ci did:

meson setup build --buildtype=release -Ddefault_library=static -Dbuild_osx_bundle=true -Dlocal_boost=true -Dvapoursynth=enabled --force-fallback-for=ffms2
cd build
ninja

And then the ./aegisub binary was able to be opened. I wanted a .app but also wasn't having much luck with meson compile osx-bundle, but since the binary itself opened, I just made the .app folder myself, moved the binary into Contents/MacOS, and added an Info.plist inside Contents specifying the bundle executable and identifier.

This makes it rely entirely on the rest of your system's dylibs so it's not optimal, but at least it works. And there's no image for this .app unless you set one, but that's not too much of a pain, it just involves setting the icon in the plist (which you might be able to mostly copy from the x86 released .app).

[frozenpandaman]

Are you still running into these issues? For what it's worth, I was able to build the binary and get it to work without errors on an M1.

Wow, really? Yep, still running into errors last I tried, though I could attempt it again, maybe something's been fixed. Asked others in the GJM Discord about it too though and anyone else who'd attempted it was facing the same problems, with Lua causing all these issues even if the build is successful. @arch1t3cht said he'll get access to an M2 machine soon so hopefully can start providing support here – I'd love to see arm64 builds being done via GitHub Actions & CI/CD.

I just made the .app folder myself, moved the binary into Contents/MacOS, and added an Info.plist inside Contents specifying the bundle executable and identifier.

Any chance you could share your build?? Would love to try it out and see if it works for me.

[ayypril]

Any chance you could share your build?? Would love to try it out and see if it works for me.

Here's the binary. It's dynamically linked so you'll probably just have to play whack-a-mole with installing the right dylibs until it works. Here's the open files the binary was using when it was running: https://gist.github.com/ayypril/73ba1de0b3d87dbb8906629772be0310

And make sure luarocks is installing the dependencies in the right place for luajit (since it seems to expect version 5.1 while homebrew by default does 5.4). I might try to build it again later in a clean VM just to see what actually is and isn't necessary. But either way, good luck!

aegisub.zip

[frozenpandaman]

Thanks, @ayypril!! I guess ideally it would be packaged into an .app so it can look in the bundle for the libs, but I only had to upgrade icu4c + dependencies, and install pulseaudio and portaudio, to get everything I was missing.

However, I'm still running into errors when the application:

It looks like it can't load MoonScript/Lua because it's still looking in /usr/local/ for them – though for Apple Silicon it should be looking in /opt/... any ideas? I really appreciate all your help here!

[arch1t3cht]

I have an M2 Mac now, so I can actually investigate these kinds of issues.

I fixed the LuaJit crashes on Silicon in 4e6af75 . The moonscript loading issues are just due to the ?data folder not being in the right place without bundling. You can either make a folder SharedSupport next to the executable and copy the automation and dictionaries folders from the source tree into it, or bundle the app with meson compile osx-bundle. The latter will probably run into issues with code signing though, so until I work that out you can resign it manually after bundling.

[arch1t3cht]

Rudimentary codesigning is also implemented now, so bundles should also work without extra steps now.