Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Using HXP complains about a missing NDLL #1786

Closed
EliteMasterEric opened this issue May 16, 2024 · 9 comments · Fixed by #1787
Closed

Using HXP complains about a missing NDLL #1786

EliteMasterEric opened this issue May 16, 2024 · 9 comments · Fixed by #1787

Comments

@EliteMasterEric
Copy link
Contributor

Reproduction

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
Copy link
Contributor

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.

lime/src/lime/system/CFFI.hx

Line 311 in 333d093

var ndllFolder = __findHaxelib("lime") + "/ndll/" + __sysName();

It may be an architecture mismatch.

@player-03
Copy link
Contributor

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

lime/src/lime/system/CFFI.hx

Lines 158 to 168 in 333d093

var haxelib = __findHaxelib("lime");
if (haxelib != "")
{
result = __tryLoad(haxelib + "/ndll/" + __sysName() + "/" + library, library, method, args);
if (result == null)
{
result = __tryLoad(haxelib + "/ndll/" + __sysName() + "64/" + library, library, method, args);
}
}

@tobil4sk
Copy link
Contributor

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

@player-03 player-03 mentioned this issue May 16, 2024
Merged
@player-03
Copy link
Contributor

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
Copy link
Contributor

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

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

@player-03
Copy link
Contributor

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

lime/src/lime/system/CFFI.hx

Lines 144 to 169 in 333d093

result = __tryLoad(programPath + "/" + library, library, method, args);
if (result == null)
{
result = __tryLoad(programPath + "\\" + library, library, method, args);
}
if (result == null)
{
result = __tryLoad(library, library, method, args);
}
if (result == null)
{
var haxelib = __findHaxelib("lime");
if (haxelib != "")
{
result = __tryLoad(haxelib + "/ndll/" + __sysName() + "/" + library, library, method, args);
if (result == null)
{
result = __tryLoad(haxelib + "/ndll/" + __sysName() + "64/" + library, library, method, args);
}
}
}

@tobil4sk
Copy link
Contributor

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
Copy link
Contributor

tobil4sk commented May 17, 2024 •
edited

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.

lime/src/lime/system/CFFI.hx

Line 58 in 333d093

if (library != "lime" || method != "neko_init")

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

However, then I'm not sure how this error is even thrown:

lime/src/lime/system/CFFI.hx

Line 309 in 333d093

else if (!lazy)

@tobil4sk
Copy link
Contributor

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:

lime/tools/CommandLineTools.hx

Line 483 in d2ea415

untyped $loader.path = $array(path + "Windows64/", $loader.path);

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:
HaxeFoundation/neko#276

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix error when locating Lime's bundled NDLLs. player-03/lime
3 participants
@player-03 @EliteMasterEric @tobil4sk