Lib.load MUST be able to load the first match found on OS X, or application will crash

[jgranick]

I forget if this was reported before. This has been a (somewhat) long-standing issue, which blocks functionality on OS X.

On other platforms, Lib.load can try multiple binaries before it finds one that's a match. You can also use try/catch blocks to use different paths. On OS X, it does not appear that try/catch can be used -- the application crashes regardless -- and it does not move onto trying the next path. If the first fails, tough.

An example of this comes from 32- and 64-bit on Mac. On 32-bit Neko, you MUST find the 32-bit binary first, otherwise you will crash. On 64-bit, it is the other way around. Since you cannot determine if Neko is running 32- or 64-bit until after the loader array has been initialized, this means we have to pick one or the other.

Finding why it does not respect the try/catch would probably solve everything. Thanks!

[jgranick]

Unfortunately, this is still a problem. Haxe 3.0.0 includes 64-bit Neko, nekovm.org and Haxe 3.0.1 include 32-bit Neko. Attempting to run OpenFL with 32-bit Neko on a 64-bit system throws the following error:

Failed to load library : /Users/joshua/Development/Haxe/lime-tools//ndll/Mac64/lime.ndll (dlopen(/Users/joshua/Development/Haxe/lime-tools//ndll/Mac64/lime.ndll, 1): no suitable image found. Did find:
/Users/joshua/Development/Haxe/lime-tools//ndll/Mac64/lime.ndll: mach-o, but wrong architecture)

Unlike other platforms, we cannot catch this error and try another binary. It will always be a hard crash until the user reinstalls Haxe 3.0.0 and DOES NOT reinstall Neko :(

[ncannasse]

If you get the "Failed to load library" then it means it's an error throw by Neko, and it should be catchable.
What I don't understand is why it's looking at ndll/Mac64 while Neko is in 32 bit mode.

Look at https://github.com/HaxeFoundation/haxe/blob/development/genneko.ml#L724 , it does add the library to $loader.path, but it should only add "64" if the neko runtime is 64 bit.

[jgranick]

Hmm, perhaps we rely upon the Neko $loaderPaths (which finds the first match) rather than trying the 64 and 32 paths separately. Ever since Haxe 2.10 or so, we need to add the loader paths ourselves in order for a Neko application to find our NDLLs

https://github.com/openfl/lime-tools/blob/master/src/CommandLineTools.hx#L603

I tried to set the loader path based upon whether Neko was 32- or 64-bit, but unfortunately, I could not find a way to detect this. Is there a good method to check? Instead, it is based currently upon the host architecture. This is why OpenFL will work on 64-bit Mac with a 64-bit Neko install, but not 32-bit.

[ncannasse]

You should be able to use neko.Lib.load("std","sys_is64",0)() to know if the Neko runtime is 64 bit.

[jgranick]

Tried that, but you can't do that as part of the init (its too soon). If we standardize on 64-bit Neko on Mac, it won't much matter anyway, I suppose

[ncannasse]

Maybe try then calling directly var is64 : Bool = untyped $loader.loadprim("std@sys_is64")(); There's no reason you shouldn't be able to it at init