libintl issue in ARM-based Macs

[sirwhinesalot]

I noticed that Linux and macOS support were added in the latest release so I just had to try it.

Unfortunately for ARM macs it doesn't work because of a dependency on the gettext libraries (particularly libintl.8.dylib). Not only is that library unavailable normally, installing it through homebrew puts it in the wrong path, and even when symlinked to the expected location it complains that it wants an x86-64 build of the library rather than the ARM64 build that homebrew downloads.

I'm not sure what the best solution is. Rosetta 2 works great to translate x86 to ARM but in that case the executable and its libraries need to be x86. Any chance x86 gettext could be bundled to workaround this issue?

I haven't tried it but I assume a similar issue would occur on ARM64 Linux (like the Raspberry Pi).

This is the error it gives:

Library not loaded: /usr/local/opt/gettext/lib/libintl.8.dylib
  Referenced from: /Users/cesar/.vscode/extensions/bartmanabyss.amiga-debug-1.6.3/bin/darwin/opt/m68k-amiga-elf/bin/as
  Reason: tried: '/usr/local/opt/gettext/lib/libintl.8.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/lib/libintl.8.dylib' (no such file), '/usr/lib/libintl.8.dylib' (no such file), '/opt/homebrew/Cellar/gettext/0.21.1/lib/libintl.8.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/lib/libintl.8.dylib' (no such file), '/usr/lib/libintl.8.dylib' (no such file)

[grahambates]

I would have expected that this would be statically linked but clearly it's not! I'll have a look at the build settings to see if I can get this working correctly. As a last resort we could bundle it and set the path with DYLD_FALLBACK_LIBRARY_PATH.

[grahambates]

Ok I can see the problem. The CI script doesn't set the -static option on Mac for binutils because it doesn't work!

export LDFLAGS="-L`brew --prefix bison`/lib -static-libstdc++" # -static is not supported, use homebrew bison

Looks like we're not the only ones with this problem and there's a potential solution here: https://stackoverflow.com/questions/30947126/building-a-cross-compile-of-binutils-on-os-x-yosemite

[sirwhinesalot]

Yeah, looks like it needs a macOS specific step to use libtool instead to do the linking. If you don't have an ARM mac available is there anything I can do to help out?

[grahambates]

Ok I think I have something working. Can you give this branch a try and see if the bundled executables work for you?

There was a simple solution for binutils. If you temporarily remove libintl.8.dylib while compiling, it will use the static libintl.a instead! FS-UAE was a different matter though. It has quite a few dependencies and the simplest thing was to just bundle them. We already do this with Linux .so files anyway.

[sirwhinesalot]

Progress! But it's not yet fully functional. Sorry for the late reply, was quite a busy Sunday for me.

Using the binaries from your branch (and after right-clicking each and every executable by hand to avoid the gatekeeper alerts...) I was able to successfully build a project.

But now FS-UAE doesn't want to run. I get this error:

Library not loaded: /usr/local/opt/glib/lib/libgthread-2.0.0.dylib Referenced from: /Users/cesar/.vscode/extensions/bartmanabyss.amiga-debug-1.6.3/bin/darwin/fs-uae/fs-uae Reason: tried: '/usr/local/opt/glib/lib/libgthread-2.0.0.dylib' (no such file), '/usr/local/lib/libgthread-2.0.0.dylib' (no such file), '/usr/lib/libgthread-2.0.0.dylib' (no such file)

The file is right there next to it, so my guess is that rpath is not set correctly. It needs to include $ORIGIN as a search location. I don't know if FS-UAE is built with CMake but CMake likes to interpret $ORIGIN as a variable and replaces it with nothing, instead of the actual string $ORIGIN which is the magic "search the same folder" string for the linker. (for a makefile you want to use $$ORIGIN, see: https://stackoverflow.com/questions/42344932/how-to-include-correctly-wl-rpath-origin-linker-argument-in-a-makefile)

Windows got it right to have that be the default behaviour x)

[grahambates]

The DYLD_FALLBACK_LIBRARY_PATH env var should tell it where to look for the dylib files. The extension now sets this when running the emulator. If you just replaced the binaries in your existing installation and didn't build the extension from my branch then this won't be set.

You can test it out be running fs-uae manually with this var set:

DYLD_FALLBACK_LIBRARY_PATH=bin/darwin/fs-uae bin/darwin/fs-uae/fs-uae

[sirwhinesalot]

Yes I just replaced the binaries in the existing installation. Setting that environment variable makes it work. I think this one is solved then, just needs an official release :)

[sirwhinesalot]

Sorry to be commenting on a closed issue but there's still some annoying linking issues with libintl, this time with GDB. However, simply copying the bundled libintl.8.dylib from the bundled fs-uae into the folder it expects (/usr/local/opt/gettext/lib) solves the issue and the extension works perfectly.

[BartmanAbyss]

no worries ;) reopening..

[grahambates]

Don't worry, I'll sort it

[BartmanAbyss]

fixed in 1.6.5