Using HXP complains about a missing NDLL

[EliteMasterEric]

Reproduction

• Use any project with a basic project.hxp file overriding the project.xml. Here is my Hello World example: https://github.com/EliteMasterEric/Flixel-HelloWorld-HXP
• Run lime test windows -debug

Expected Result

The program should build and run as it does with the HXP disabled (easily test this by renaming the HXP file).

Actual Result

The following error is displayed:

Uncaught exception - Could not find lime.ndll. This file is provided with Lime's Haxelib releases, but not via Git. Please copy it from Lime's latest Haxelib release into either E:\Programming\Haxe\Flixel-HelloWorld\.haxelib\lime/8,1,1/src//ndll/Windows or E:\Programming\Haxe\Flixel-HelloWorld\.haxelib\lime/8,1,1/src//ndll/Windows64, as appropriate for your system. Advanced users may run `lime rebuild cpp` instead.

Note the incorrect file path (./src); the NDLL file does exist if you look in the correct file path.

Version info

Haxe 4.3.4 HXP 1.3.0 Lime 8.1.1

[tobil4sk]

Note the incorrect file path (./src); the NDLL file does exist if you look in the correct file path.

I think that this is just a bug with the error message. __findHaxelib here gives the haxe source path of the library, not the root path.

https://github.com/openfl/lime/blob/333d093df0d347967a3dde2f03762b1e9ebc24a0/src/lime/system/CFFI.hx#L311

It may be an architecture mismatch.

[player-03]

Not just the error message. The search function also uses __findHaxelib().

https://github.com/openfl/lime/blob/333d093df0d347967a3dde2f03762b1e9ebc24a0/src/lime/system/CFFI.hx#L158-L168

[tobil4sk]

@EliteMasterEric Could you try running with the OPENFL_LOAD_DEBUG environment variable set?

[player-03]

So I think there are two things wrong here. First, your class name doesn't match your file name. Either name the class Project or name the file helloWorldProject.hxp. Second, Lime should be calling haxelib libpath instead of haxelib path, since the latter adds that extraneous "src/". Check out my pull request and see if that helps.

[tobil4sk]

Not just the error message. The search function also uses __findHaxelib().

Hm... How is lime.ndll being loaded at all then?

[player-03]

One of the other branches must be working. What I quoted was the "if all else fails" case.

https://github.com/openfl/lime/blob/333d093df0d347967a3dde2f03762b1e9ebc24a0/src/lime/system/CFFI.hx#L144-L169

[tobil4sk]

It may be useful to add this line somewhere:

__loaderTrace("Using neko loader path: " + neko.vm.Loader.local().getPath());

It will help us figure out which paths are being used when debugging these issues.

[tobil4sk]

One of the other branches must be working. What I quoted was the "if all else fails" case.

In theory, with the lime tools, optional-cffi is enabled so unless we're loading neko_init from lime, we should be doing lazy loading.

https://github.com/openfl/lime/blob/333d093df0d347967a3dde2f03762b1e9ebc24a0/src/lime/system/CFFI.hx#L58

That would mean that those fallbacks aren't being used...

However, then I'm not sure how this error is even thrown: https://github.com/openfl/lime/blob/333d093df0d347967a3dde2f03762b1e9ebc24a0/src/lime/system/CFFI.hx#L309

[tobil4sk]

In theory, with the lime tools, optional-cffi is enabled

Ah, this error doesn't come from lime tools, it comes from the hxp script after it has been compiled. The lime tools have the paths added in: https://github.com/openfl/lime/blob/d2ea41570bc195bd3c1ded9e67a2881b3cf31df2/tools/CommandLineTools.hx#L483

However, in the hxp script no loader paths are added. This means it only uses neko's built in ones, which only adds Windows and not Windows64 due to a bug in neko: https://github.com/HaxeFoundation/neko/pull/276