-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
lime.ndll
fails to load libneko.dylib
with certain homebrew installs of haxe/neko
#1750
Comments
Here is a hacky patch that implements this solution: tobil4sk@a308fe7 |
It is a problem to link lime.ndll to libneko like this, because with cpp builds, libneko should not be a dependency. It turns out it is enough to set the rpath, because dlopen respects rpath. Here is an updated patch: tobil4sk@cae2458 Perhaps it is best to remove the rpath (using |
This seems to be required with Xcode 15, but was not required previously
…brew/lib to rpath of lime.ndll Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable. I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths. As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
Reopening for now while we figure out what's going on with: 4793649 |
Thanks for testing this out! I'm still a bit confused about the difference with installing haxe/neko via different methods. Via the universal installer (a nightly build is now available), there is no need for this patch still, but with homebrew it is necessary. I'd imagine that the homebrew build is probably built with xcode 15+. The x86_64 neko build is built on macos-12, which still has xcode 14, but the arm64 build is on macos-14 which has xcode 15. But then these binaries are combined to create the universal binary (also in macos-14). I wonder if neko x86_64 being built on xcode 15 would make this patch necessary with the installer build as well, or if there is something wrong with the homebrew setup of neko. |
When haxe/neko are installed via homebrew, they are installed to
/opt/homebrew
on an Apple Silicon Mac system. This means that libneko exists in/opt/homebrew/lib
rather than the traditional paths. As a result, whenlime.ndll
tries to loadlibneko.dylib
(viadlopen
), it fails because dlopen does not check the homebrew path.Running a
lime
command from the terminal gives the error:Homebrew does not have a solution for this problem: Homebrew/brew#13481.
To work around this, it is possible to set
DYLD_LIBRARY_PATH
to/opt/homebrew/lib
, but this only works if System Integrity Protection is disabled, which is not ideal.One possible option is for
lime.ndll
to have a hardcoded full path tolibneko
(by setting install_name). However, system specific paths wouldn't really work for the precompiled lime.ndlls distributed via haxelib. Also, this would only work if lime.ndll is compiled with-lneko
, which is currently not the case.Also, it looks like
/usr/local/lib
may not be a default path anymore either: https://developer.apple.com/forums/thread/737920.Not sure if this is the best place to put this, but lime won't work natively on Apple Silicon without resolving this.
The text was updated successfully, but these errors were encountered: