Skip to content

Commit

Permalink
Build.xml: on macOS, add /usr/local/lib to rpath when building lime.ndll
Browse files Browse the repository at this point in the history 
This seems to be required with Xcode 15, but was not required previously
  • Loading branch information
@joshtynjala
joshtynjala committed May 9, 2024
1 parent bb3b31b commit c70ec9f
Showing 1 changed file with 5 additions and 0 deletions.
5 changes: 5 additions & 0 deletions project/Build.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -442,6 +442,11 @@
</section>

<section if="mac">
<!--
starting in xcode 15, rpath doesn't automatically include
/usr/local/lib, but we need it for neko
-->
<vflag name="-rpath" value="/usr/local/lib" />

<vflag name="-l" value="iconv" />
<vflag name="-framework" value="IOKit" />
Expand Down

6 comments on commit c70ec9f

@tobil4sk
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joshtynjala Note, this assumes that neko is installed in /usr/local/lib, which isn't always the case, see: #1750

@joshtynjala
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tobil4sk Yeah, I'm aware that Apple Silicon Homebrew installs haxe/neko in /opt/homebrew.

The fact is, if lime.ndll is built with Xcode 15, Neko builds don't seem to work at all. Something changed between Xcode 14 and Xcode 15 in how default library paths work. So lime.ndll built with Xcode 14 works correctly, and lime.ndll built with Xcode 15 does not. A fix is needed, or we'll be forced to stop supporting Neko on macOS entirely. Which we might do eventually, but it doesn't seem necessary when the fix is this straightforward.

I did extensive testing of this change today, and I confirmed that adding /usr/local/lib to the rpath works both when using the official haxe/neko .pkg installer from haxe.org/download and when haxe/neko are installed with Intel Homebrew.

@joshtynjala
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tobil4sk I should add that this commit is also on Lime's develop branch, which I don't think supports Apple Silicon builds at all. Regardless, I actually tried rebuilding lime.ndll with Apple Silicon Homebrew haxe/neko in the 8.2.0-Dev branch, but compilation of lime.ndll doesn't finish successfully, so I guess more work is still needed there. If I could get a proper build of lime.ndll for Apple Silicon, I totally would have tried adding a conditional to choose between /usr/local/lib and /opt/homebrew/lib based on the current architecture. That seems easy enough.

I'll be curious to see where the Haxe team decides to install haxe/neko whenever they get around to creating a .pkg installer for Apple Silicon. I assume it won't be in /opt/homebrew/lib.

@tobil4sk
Copy link
Member

@tobil4sk tobil4sk commented on c70ec9f May 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding /usr/local/lib to the rpath works both when using the official haxe/neko .pkg installer from haxe.org/download and when haxe/neko are installed with Intel Homebrew.

@joshtynjala This makes sense, both of them install it to /usr/local/lib.

If I could get a proper build of lime.ndll for Apple Silicon

This is possible now with patches to various dependencies, I'm tracking all the patches required for this here: #1640

I'll be curious to see where the Haxe team decides to install haxe/neko whenever they get around to creating a .pkg installer for Apple Silicon. I assume it won't be in /opt/homebrew/lib.

This is WIP, see: HaxeFoundation/haxe#11663. There will be a universal .pkg installer which will support Apple Silicon and Intel. So I guess this will install to /usr/local/. This means that on Apple Silicon, arm64 neko will either be in /usr/local/ if installed via the installer, or in /opt/homebrew/ if installed via arm64 homebrew... and who knows what package managers might exist in the future... will lime have to be aware of every possible way to install neko?

But for now, we should be able to support both by doing:

<vflag name="-rpath" value="/usr/local/lib" />
<vflag name="-rpath" value="/opt/homebrew/lib" if="HXCPP_ARM64" />

I think it should try both paths until it finds a libneko that exists and has the expected architecture. So if an arm64 build of lime.ndll finds x86_64 libneko in /usr/local/, I think it would just continue looking in /opt/homebrew/. I haven't tested this behaviour though.

However, another concern is that these rpath values are only needed when loading lime.ndll in a neko context. It is a security issue to have these around unnecessarily as it could allow an unintended library to be loaded (this concern is presumably why Apple is changing default loading behaviours). Therefore, it might be good to further modify lime.ndll when it is copied into a project build folder to remove the rpath (via install_name_tool). Mainly for CPP builds, which won't be loading libneko at all. I'm not sure about neko builds, I guess those still need to load libneko.

@joshtynjala
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if an arm64 build of lime.ndll finds x86_64 libneko in /usr/local/, I think it would just continue looking in /opt/homebrew/. I haven't tested this behaviour though.

Based on some of the behavior I was observing yesterday, I think you are correct about this.

Therefore, it might be good to further modify lime.ndll when it is copied into a project build folder to remove the rpath (via install_name_tool). Mainly for CPP builds, which won't be loading libneko at all. I'm not sure about neko builds, I guess those still need to load libneko.

Yes, this makes senses for cpp builds.

This means that on Apple Silicon, arm64 neko will either be in /usr/local/ if installed via the installer, or in /opt/homebrew/ if installed via arm64 homebrew... and who knows what package managers might exist in the future... will lime have to be aware of every possible way to install neko?

With a small number of options that we have currently, it's not much of a burden. But yes, we'll need to watch out for other, new locations in the future.

That leads me to this...

So as I understand things in Lime currently, running an .app file targeting Neko requirse libneko to be installed separately. That's fine on the developer's machine, but if the developer wants to distribute it to end users (for whatever reason, even though C++ or HashLink is probably better), those end users probably shouldn't be required to install Neko. Ideally, the .app file should "just work" without separate dependencies. I recently got that working for HashLink builds in the 8.2.0-Dev branch. A similar approach may make sense for Neko builds.

c26a73f

@tobil4sk
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this makes senses for cpp builds.

I've opened a PR, I'm not too sure where to add this install_name_tool command: #1783

A similar approach may make sense for Neko builds.

This is probably doable, but given that lime neko apps have worked like this forever, and given that neko is deprecated software, I'm not sure if there is a point in implementing this. Most people probably wouldn't use the neko target to distribute an app to an end user, and if there is anyone doing this, they are probably already used to requiring neko as a separate install. New projects should definitely be choosing hxcpp or hashlink over neko.

Please sign in to comment.