-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libintl issue in ARM-based Macs #145
Comments
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 |
Ok I can see the problem. The CI script doesn't set the 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: |
Yeah, looks like it needs a macOS specific step to use libtool instead to do the linking. |
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 |
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 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 Windows got it right to have that be the default behaviour x) |
The You can test it out be running
|
Yes I just replaced the binaries in the existing installation. Setting that environment variable makes it work. |
Sorry to be commenting on a closed issue but there's still some annoying linking issues with libintl, this time with GDB. |
no worries ;) reopening.. |
Don't worry, I'll sort it |
refs BartmanAbyss#145 I think the previous file got overwritten by the 'without guile' PR.
fixed in 1.6.5 |
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:
The text was updated successfully, but these errors were encountered: