Oh, I almost forgot.
One other option is to embed Neko ourselves, I’m not sure if this helps resolve certain issues. Instead of using the precompiled Neko binaries, we actually put Neko inside of the Lime NDLL. Then we could have a small wrapper C++ application that’s precompiled, and just boot up Neko from there (and possibly resolve the paths properly and such)
@singmajesty There’s a discusson on the Haxelang mailing list about this. Andreas suggested using xcross. I tried it, against what comes out of Lime, but I get a runtime error.
Andreas Mokros wrote:
You’re right. I see that as well now. I have a neko executable and it can’t load libneko.so in the same.
In the same directory that should be.
There’s something wrong with loading libneko it seems.
It works for me with xcross. Did you try this? xcross creates excutables with libneko and some ndlls statically linked in.
I don’t know much about the OpenFL pipeline. Is it possible to integrate xcross into the intermediary output from neko? Is this an easier way to solve the problem, or is this already your conclusion (statically link)?
Okay, technical details 
If you append a Neko binary file to the end of the Neko EXE, it will automatically run it. This is the difference between “neko myfile.n” and “myfile.exe”, like what “nekotools boot myfile.n” creates.
The Neko executable looks for a few dynamic libraries, libneko, std, etc. In the code for looking for these references, Neko expects to load them dynamically in another file.
However, in xcross, it’s changed to be built with libneko, std and other dependencies statically linked into the Neko executable. Instead of expecting to load an external file, it expects everything to already be available in the executable.
This is alright for standard Neko stuff, but we need it to load our Lime binary as well. Either it needs to be able to know how to find symbols both in itself (for libneko, etc) as well as externally, or we need to build Lime and link it with Neko ourselves.
Do you mean to say nekotools boot myfile.n creates a file which is your neko binary followed by your .n file?
Now, a different question: How does OpenFL use neko? Some points:
/usr/bin/neko.DT_RPATH feature. (I didn’t read or understand the post.)readelf -D neko shows RPATH in the list).A version of Neko that correctly finds libraries located in the same directory
/usr/bin/neko with his version. (First, I verified that removing it breaks lime; then, I put his over it.)export and ran my app with lime test neko -clean. It builds and runs fine.readelf -D neko against my binary, and RPATH is not present.Andreas said:
readelf for [your] game executable:
But this is not [correct]. The rpath stuff is missing there. I don’t know how OpenFL creates neko executables. I thought it simply uses
nekotools boot. Maybe you can ask on a OpenFL forum.
If, for some reason, you’re interested in seeing his custom neko binary, I’ve uploaded it here. It’ll probably auto-delete after 7 days.
What can you tell us about how OpenFL uses neko to build the final executable? (I tried using Neko and Haxe in a trivial hello-world example (no real code, just a trace statement), and then building the executable with nekotools boot Hello.n, and it does show RPATH.)
Interesting post, it would indeed fix your problem and it’s easy to make such a version of neko (just need to add -Wl,-rpath,\$ORIGIN to the NEKOVM_FLAGS var of neko’s makefile)
/usr/bin/neko is used by haxelib, itself used by the lime/openfl command line tool.
But it uses its bundled version of neko to build executable and not nekoc.
Until @singmajesty update lime with a new linux neko you can replace /usr/lib/haxe/lib/lime/version/templates/neko/bin/neko-linux (or neko-linux64 depending of the arch) with Anderas’ version.
@ibilon it doesn’t seem to work. The new binary isn’t built with his neko executable, the one from the directory you mentioned.
Even if I delete .../templates/neko/bin, I can still build with lime. Only if I delete /usr/bin/neko, does lime test neko stop working – which is why I thought the /usr/bin/neko binary is the one lime used and the one I should replace. Even if lime is using the templates one to build, the build should fail if I delete it. It doesn’t.
At any rate, I replaced both, and I can confirm that the executable doesn’t have RPATH in it. Any thoughts on why?
Andreas mentioned that this works with (and I verified that it works with) nekotools boot blah.n. Is that how Lime builds it? I don’t know if this affects nekoc.
/usr/bin/neko is what “lime test” will use to run the tools
templates/neko/bin is what the Lime tools will use when creating your Neko-based binary. Similar to how “nekotools boot” works, Lime will combine the binary in that template directory with the compiled *.n file, so replacing the files in templates/neko/bin, then running “lime test neko”, accomplishes the same thing as “nekotools boot” would, but using your custom Neko binary
@singmajesty if that’s true, then why don’t I see RPATH when I replace both binaries? It seems like it’s not using /usr/bin/neko.
If templates/neko/bin is used to create my final binary, why do I still get a binary when I delete /templates/neko/bin, rm -rf assets and run lime test neko -clean? Shouldn’t I get an error, or a non-functional build at best?
To clarify again, Andreas’ fix works if you run:
haxe MainClass -neko out.nnekotools boot out.n./outIs Andreas’ neko build useful for you to solve this problem?
Oh, I almost forgot. There’s “lime/templates/neko/bin” and “lime/legacy/templates/neko/bin”, try replacing the “lime/legacy” versions
@singmajesty I can confirm that my HaxeFlixel hello-world game (finally!!!) works on a clean Linux VM with Andreas’ changed neko binary:
/usr/bin/neko
templates/neko/bin
legacy/templates/neko/bin
Thanks again for your help, and @ibilon too.
There’s currently a pull request from Andreas to integrate this to Haxe itself. The final questions I have:
Well it is a security risk sure, a bad guy could put a malicious libneko.so next to a neko executable, and if this exe has some special security authorizations then he gets these permissions, but you’re not supposed to put these kind of exe in a user writable directory anyway.
So I can understand Nicolas’ concerns since you can use neko to do any kind of application, maybe that’s worrying too much maybe not.
But since it’s unlikely you’d use openfl to make a security sensitive app and not a game that’s not really a problem. Personally I think we should replace the neko template with this version, and copy libneko.so, std.ndll … too to the export folder, that way you can ship the folder to someone who don’t have neko. (@singmajesty that’s probably required for the new deploy command right?)
Hey @singmajesty @ibilon I’m not sure if you two are monitoring Andreas’ pull request. I asked him, and he said his fork of neko is on GitHub.
I don’t know yet if this goes into Haxe or not, but please keep tabs too. I’ll post here if I see any updates.
I’m hoping that pull request goes through, and that’s all we need. Even without waiting, we could include updated Neko Linux binaries in our templates, if this is all we need to solve it
If it does solve it, then I think with a little work, the cross-desktop behavior could be patched up in the tools. My intention was to make “lime test windows” use C++ by default if you’re using Windows (unless you specify -neko) but to make “lime test windows” use Neko by default if you’re not using Windows, and instead generate a Neko build
@singmajesty it solved it for me when I tested this case with Andreas’ build.
Edit: It looks like the PR is going through. Please let me know when there’s a new Lime biuld available so I can re-test my app (again).
Are there any updates on this @ibilon or @singmajesty ? The last update to this thread was about three weeks ago. I didn’t see the Haxe PR go through yet either.
Time flies, well if the pr doesn’t pass I guess the simplest would be to build neko linux ourselves with the modification and update the bundled version.
Since we’d have to change the version in the template if neko is updated anyway.
@singmajesty I’ll make a pull request.
(edit) Well it’ll have to wait a couple of hours I’m back with my main computer, for some reason neko doesn’t want to compile on my laptop
Done.
I think the PR will still go through. I’m not in a hurry to get this done, but I am concerned that there’s not much movement over three weeks.
Should we just wait it out?
Waiting for an official build won’t get us more than doing it ourselves, just later.
Thanks for clarifying. Is there an approximate timeline for the next Lime release?