Flashdevelop/haxedevelop build Neko is it possible still from OpenFL project? Fails to compile.

[GitMepc7r]

I made a fresh reinstall of Win 11 Home 22H2 because previously I tried renaming the AppData username and even though I fixed paths in Registry it caused some permission w issues writing to the user/documents/.(folders) like Gimp was crashing and so was probably Lime config.xml.

Now that I started anew, installed Haxe ToolKit with neko and haxe and then

haxelib install lime haxelib run lime setup lime install openfl

To install LIME libs.

And a simple project will not work when trying to build Neko, example: (but programs I have built like that before 2020 work but I cant update them if I cant compile again)

Error for below code is:

Called from lime/_internal/backend/native/NativeCFFI.hx line 613 Called from lime/system/CFFI.hx line 172 Called from lime/system/CFFI.hx line 306 Uncaught exception - Could not find NekoAPI interface.

if that matters I have C:\Users\Me\.lime\config.xml and is just

<config>
<section id="defines"> </section>
</config> 

(do I need to get a proper LIME config and how and where is it stored on the hard disk?)

This is a simple project that will not compile

package;

import openfl.Assets;
import openfl.display.Bitmap;
import openfl.display.BitmapData;
import openfl.display.Sprite;
import openfl.Lib;

/**
 * ...
 * @author Me
 */
class Main extends Sprite 
{

    public function new() 
    {
        super();

        // Assets:
        // openfl.Assets.getBitmapData("img/assetname.jpg");

        var iTestPic:Bitmap = new Bitmap(Assets.getBitmapData("img/testpic.jpg"));
        addChild(iTestPic);
    }

}

[player-03]

Can you check in lime/ndll/Windows and lime/ndll/Windows64 for a file called lime.ndll? If you're not sure where the Lime directory is, run haxelib path lime.

[GitMepc7r]

Yes the file is in both folders

[player-03]

Can you try moving or renaming the 32-bit one? I recently noticed that it prefers that one even on 64-bit machines. Don't know why it does that.

Not really expecting it to matter, because it usually works fine regardless, but I want to be sure.

[tobil4sk]

I recently noticed that it prefers that one even on 64-bit machines

This may be related to a neko bug: https://github.com/HaxeFoundation/neko/pull/276

[player-03]

This may be related to a neko bug

Completely unrelated, but I might have to take it back anyway. The code in question is the final fall-through case if all else fails, and probably never gets run.

[player-03]

@GitMepc7r, let's move on to the next step: getting an actually useful error message. As is, CFFI.hx swallows the original error in order to print "Could not find NekoAPI interface", but we can remove that and get the error back.

Please delete the following lines, then run lime rebuild tools, then try again.

-           try
-           {
                var init = load("lime", "neko_init", 5);

                if (init != null)
                {
                    __loaderTrace("Found nekoapi @ " + __moduleNames.get("lime"));
                    init(function(s) return new String(s), function(len:Int)
                    {
                        var r = [];
                        if (len > 0) r[len - 1] = null;
                        return r;
                    }, null, true, false);
                }
-               else if (!lazy)
-               {
-                   throw("Could not find NekoAPI interface.");
-               }
-           }
-           catch (e:Dynamic)
-           {
-               if (!lazy)
-               {
-                   throw("Could not find NekoAPI interface.");
-               }
-           }

You should get a new error this time, hopefully one that provides a good hint.

[GitMepc7r]

I rename to bak the NDLL from the 32 bit windows folder and same message as in the OP. I edited the CFFI as you said I get:

Called from lime/_internal/backend/native/NativeCFFI.hx line 613 Called from lime/system/CFFI.hx line 172 Called from lime/system/CFFI.hx line 283 Called from lime/system/CFFI.hx line 111 Called from D:\Applications\HaxeToolkit\haxe\std/neko/Lib.hx line 35 Uncaught exception - load.c(237) : Failed to load library : ./lime.ndll

[player-03]

Ugh, ok, ./lime.ndll. I've seen that before but wasn't able to figure out what was going on. This time I found where it adds the "./", at least.

if( stat(val_string(ff),&s) == 0 ) { //If the file exists...
    char *p = strchr(file,'/');
    if( p == NULL ) //...but doesn't have any forward slashes...
        p = strchr(file,'\\');
    if( p != NULL ) //...or backslashes...
        return ff;
    b = alloc_buffer("./"); //...insert "./" at the beginning.
    buffer_append(b,file);
    buffer_append(b,ext);
    return buffer_to_string(b);
}

I'm pretty sure it adds the slash because dlopen() functions differently depending on whether there's a slash or not. Fair enough, but Windows uses GetModuleHandle() instead.

        value pname = pname = neko_select_file(path,prim,".ndll");
#ifdef NEKO_STANDALONE
#   ifdef NEKO_WINDOWS
        h = (void*)GetModuleHandle(NULL); //Probably here? Even though `pname` isn't used.
#   else
        h = dlopen(NULL,RTLD_LAZY);
#   endif
#else
        h = dlopen(val_string(pname),RTLD_LAZY); //This uses `pname` but shouldn't work on Windows.
#endif

To be quite honest I have very little idea what's going on in Neko. And even if we did figure it out, they aren't doing bug fixes anymore. We're on our own. Ideally, we want to fix this without changing Neko. (At least partially because I don't know how to compile it.)

---

Next, try inserting the absolute file path at CFFI.hx line 111:

                #else
+               if (__moduleNames.get(library) == "lime")
+                   return neko.Lib.load(__findHaxelib("lime") + "/ndll/Windows64/lime", method, args);
                return neko.Lib.load(__moduleNames.get(library), method, args);
                #end

You'll have to lime rebuild tools again, as with any change to Lime.

[GitMepc7r]

I did add the two lines to the file at line 111. Then I had to do

haxelib install format haxelib install hxp lime rebuild tools

Then when trying to build Neko project in FlashDevelop the error is

Called from D:\Applications\HaxeToolkit\haxe\std/neko/Lib.hx line 35
Uncaught exception - load.c(237) : Failed to load library : D:\Applications\HaxeToolkit\haxe\lib\lime/8,0,1/src//ndll/Windows64/lime.ndll

If neko doesnt work I can try Windows, just trying to make a windows build for it, I thought neko was the only one doing it. Windows build also has some errors om compile like Error: 64bit is not automatically supported for this version of VC. Set HXCPP_MSVC_CUSTOM but I have yet to look into fixing a windows build.

[player-03]

Ok, I'm getting the impression that it can find the file just fine, but it just can't use it for some reason. To confirm this, let's try the workaround I found last time.

1. Comment out lines 111-112 so that it'll look for ./lime.ndll again. (Rebuild tools as usual.)
2. Copy lime.ndll into your project's root directory.
3. Run lime build neko from the project's root directory. (Build via the command line for this one, not via FlashDevelop.)

This way, we're sure it can find ./lime.ndll (because it's literally right there). So if it still errors, we'll know it just doesn't like the file for some reason.

lime/8,0,1/src//ndll/Windows64

Whoops, double slash. Not that it matters. You can often add extra slashes like that, and in this case I'm 90% sure that it isn't actually using the path at all. It just prints it in the error message and then discards it.

And if it did use the path, the fact that it contains forward slashes would be a bigger problem. You could fix it like this: StringTools.replace(neko.Lib.load(__findHaxelib("lime"), "/", "\\") + "ndll\\Windows64\\lime", but again, I don't think it actually uses the string.

If neko doesnt work I can try Windows

Won't help. It still uses Neko to compile, which requires lime.ndll. There's another way around that, which I think is going to be required, but I'll get to that later.

[GitMepc7r]

I removed the previously added lines after 111 and rebuilt lime tools. I ran the lime build neko from FD's command prompt and it creates a build with no errors seen but when I start the app from the built neko folder it exits quickly so no way to tell what is going on.

When I try ti build again with FlashDevelop Release Neko it gives

Uncaught exception - load.c(237) : Failed to load library : ./lime.ndll

The only difference is it doesn't now give the full path to whichever D drive but same error in the local or root folder (I put the lime.NDLL in the projects folder along with the HXproj file, I did not put it in any subfolders

[player-03]

I ran the lime build neko from FD's command prompt and it creates a build with no errors seen but when I start the app from the built neko folder it exits quickly so no way to tell what is going on.

Try lime run neko from the main project folder. That will not only run the app, but since you're starting it from the command line, you'll be able to see error messages even after it closes.

For future reference, you can also do lime test neko, which will build and then run it in a single step. (Note that if lime build neko && lime run neko doesn't work, then lime test neko won't either, and vice versa. Don't get bogged down trying both every single time.)

I put the lime.NDLL in the projects folder along with the HXproj file, I did not put it in any subfolders

I assume that's the folder with the project.xml file?

[GitMepc7r]

Yes, lime run neko / lime test neko give the same error

Called from lime/_internal/backend/native/NativeCFFI.hx line 613
Called from lime/system/CFFI.hx line 172
Called from lime/system/CFFI.hx line 283
Called from lime/system/CFFI.hx line 111
Called from D:\Applications\HaxeToolkit\haxe\std/neko/Lib.hx line 35
Uncaught exception - load.c(237) : Failed to load library : ./lime.ndll

Yes the project.XML is there, so is the lime.ndll

[player-03]

Ok, I'm pretty much out of ideas for making lime.ndll work. Let's try a different approach.

I just merged a new feature into the 8.1.0-Dev branch that allows you to skip lime.ndll entirely. It's still kind of experimental, but as far as I know it just works.

In case you aren't familiar with the process of cloning a repo and checking out a branch, here are the steps:

haxelib git lime https://github.com/openfl/lime.git
haxelib path lime
cd [path to lime/git]
git fetch
git checkout 8.1.0-Dev

Once done, you should be able to compile with lime test [target] -eval. First try this from the command line, and then we'll try to figure out how to make FlashDevelop do it automatically.

[hoangdung-qbt]

I made a fresh reinstall of Win 11 Home 22H2 because previously I tried renaming the AppData username and even though I fixed paths in Registry it caused some permission w issues writing to the user/documents/.(folders) like Gimp was crashing and so was probably Lime config.xml.

Now that I started anew, installed Haxe ToolKit with neko and haxe and then

haxelib install lime haxelib run lime setup lime install openfl

To install LIME libs.

And a simple project will not work when trying to build Neko, example: (but programs I have built like that before 2020 work but I cant update them if I cant compile again)

Error for below code is:

Called from lime/_internal/backend/native/NativeCFFI.hx line 613 Called from lime/system/CFFI.hx line 172 Called from lime/system/CFFI.hx line 306 Uncaught exception - Could not find NekoAPI interface.

if that matters I have C:\Users\Me.lime\config.xml and is just

<config>
<section id="defines"> </section>
</config> 

(do I need to get a proper LIME config and how and where is it stored on the hard disk?)

This is a simple project that will not compile

package;

import openfl.Assets;
import openfl.display.Bitmap;
import openfl.display.BitmapData;
import openfl.display.Sprite;
import openfl.Lib;

/**
 * ...
 * @author Me
 */
class Main extends Sprite 
{

  public function new() 
  {
      super();

      // Assets:
      // openfl.Assets.getBitmapData("img/assetname.jpg");

      var iTestPic:Bitmap = new Bitmap(Assets.getBitmapData("img/testpic.jpg"));
      addChild(iTestPic);
  }

}

Try adding <architecture name="x86" exclude="x64" if="windows" unless = "neko"/> to your project.xml. It really worked for me. It seems lime copied wrong ndll file when compiling. You can also change this line if you target 64bit build.

[player-03]

This seems to have been a one-off, so I don't think we need to keep the issue open.

[tobil4sk]

If this comes up again, it might be useful to try debugging with the OPENFL_LOAD_DEBUG environment variable set.