Neko Doesn't Search Current Path on Linux

[Ashiq A.]

Hi,

TLDR: I'm trying to create a stand-alone zip of my Neko game (I need
neko for the plugin architecture I wrote about earlier). I can get
this working on Windows, but not Linux, because of how Neko looks for
NDLLs.

Can someone comment on this post:
http://community.openfl.org/t/stand-alone-neko-executables-with-neko/770/5?u=ashes999

Basically, if I create a HaxeFlixel game against the Neko target on
Windows, and add std.ndll, regexp.ndll, and zlib.ndll to the final
zip, I can run it on a clean VM. On Linux, I get an error: "error
while loading shared libraries: libneko.so: cannot open shared object
file: No such file or directory" (even when libneko.so is in the
executable directory).

1) Is there any work-around to this? I can ask users to do things like
setting LD_LIBRARY_PATH, but I'd rather not have them do any
setup/changes

2) Is it possible to fix Neko itself, on Linux, so that it behaves the
same way as it does on Windows?

--Ashiq

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 10:10:13 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> On Linux, I get an error: "error
> while loading shared libraries: libneko.so: cannot open shared object
> file: No such file or directory" (even when libneko.so is in the
> executable directory).
>
> 1) Is there any work-around to this?

Try this:
untyped $loader.path = [".".__string(),$loader.path];

--
Mockey

[Ashiq A.]

Hi Andreas,

I tried it, and I get the same error.

Tracing $loader.path gives me something which includes @executable_path:

Main.hx:28: Loader
path:[.,[@executable_path/,[./,[/usr/bin,[/usr/bin/,[/usr/local/bin/,[/usr/lib/neko/,[/usr/local/lib/neko/,null]]]]]]]]

Thanks,

--Ashiq

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 11:12:46 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> I get an error: "error
> while loading shared libraries: libneko.so: cannot open shared object
> file: No such file or directory"

What exactly are you running there? Is this a neko exe created with
nekotools? This should not look for libneko.so.

> I tried it, and I get the same error.
> Tracing $loader.path gives me something which includes
> @executable_path:

You have all the libs in the same directory as the executable, right?

--
Mockey

[Ashiq A.]

Right, I have all the libs in the same directory as the executable.

I'm running a HaxeFlixel game, built against Neko. I built it on a
machine that has HaxeFlixel/OpenFL/Neko/Haxe, then copy over the
binaries, plus the neko NDLLs, dump them into one directory, and try
to run it.

I'm trying to create a complete zip that has my HaxeFlixel/Neko game,
on Linux, that doesn't require Linux users to download Neko
themselves.

This same workflow, from Windows to Windows, works. For Linux to
Linux, it doesn't.

--Ashiq

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 11:40:14 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> I'm running a HaxeFlixel game, built against Neko. I built it on a
> machine that has HaxeFlixel/OpenFL/Neko/Haxe, then copy over the
> binaries, plus the neko NDLLs, dump them into one directory, and try
> to run it.

I don't use OpenFL. What binaries are created there? Only Linux or
Win/Mac as well? libneko.so is included and std.ndll?

> For Linux to Linux, it doesn't.

You're right. I see that as well now. I have a neko executable and it
can't load libneko.so in the same. Maybe libneko has to be in
LD_LIBRARY_PATH?

--
Mockey

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 18:30:43 +0100
Andreas Mokros <m...@medienpensionat.com> 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.

--
Mockey

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 18:45:18 +0100
Andreas Mokros <m...@medienpensionat.com> wrote:
> It works for me with xcross. Did you try this? xcross creates
> excutables with libneko and some ndlls statically linked in.

Don't know if this works with OpenFL, though.

--
Mockey

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 10:10:13 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> I can ask users to do things like
> setting LD_LIBRARY_PATH, but I'd rather not have them do any
> setup/changes

As a workaround you could add a shell script in your install dir with:
export LD_LIBRARY_PATH=$(pwd) && ./game_exe
and tell the user to run this.

--
Mockey

[Ashiq A.]

Andreas: that's what I ended up doing. Ideally, I would like to see
Neko behave the same across both platforms.

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 13:18:11 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> There's something different about OpenFL's use of Neko. It can target
> all the Haxe targets (neko, windows, linux, presumably mac) plus
> Android and iOS.

I know. But can you compile a windows-neko-exe on Linux with OpenFL?
Most of the OpenFL users compile with cpp, don't they?

> The binaries that come out are not exactly the same as running haxe
> -neko ... -- xcross doesn't work against OpenFL binaries (I get a
> std_read error). I'll ask Joshua if he can take a look.

Are there no .n files somewhere? You need the .n files for xcross.

> Does it make sense to change Neko itself, on Linux, to act like the
> Windows one -- that it probes the current directory for the Neko
> runtimes, in addition to the location specified by the environment
> variable? That would solve my issue.

Would make sense IMO.

--
Mockey

[Ashiq A.]

1) Should I open a GitHub issue for this then? What's the next step?
2) I don't know. I didn't know you can compile a Windows Neko app on
Linux with Haxe.
3) Most of the OpenFL users use Flash, I guess, or Android/iOS. I use
Neko because I need to load .n files at runtime that are not
necessarily present at compile time.
4) There are no .n files. I don't know what exactly the final binary
is, but I know it runs on Neko.

[Ashiq A.]

There's something different about OpenFL's use of Neko. It can target
all the Haxe targets (neko, windows, linux, presumably mac) plus
Android and iOS.

The binaries that come out are not exactly the same as running haxe
-neko ... -- xcross doesn't work against OpenFL binaries (I get a
std_read error). I'll ask Joshua if he can take a look.

Does it make sense to change Neko itself, on Linux, to act like the
Windows one -- that it probes the current directory for the Neko
runtimes, in addition to the location specified by the environment
variable? That would solve my issue.

--Ashiq

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 13:19:06 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> Andreas: that's what I ended up doing. Ideally, I would like to see
> Neko behave the same across both platforms.

export LD_LIBRARY_PATH=$(dirname $0) && ./game_exe

is better. Script can be run from outside directory then.

--
Mockey

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 13:40:07 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> 1) Should I open a GitHub issue for this then? What's the next step?

As far as I understand, it is the normal Linux behaviour that a shared
library (libneko.so) is searched in the standard lib-places and in
LD_LIBRARY_PATH and not in the current working directory (as in
Windows).

> 2) I don't know. I didn't know you can compile a Windows Neko app on
> Linux with Haxe.

with haxe you compile a .n-file (that you can run everywhere)

with 'nekotools boot' you compile an executable (that unfortunately
needs libneko.so to run), I suppose that's what OpenFL does

with xcross you can create a statically linked neko executable for
win/mac/lin, but I don't know if that exe can also load dynamic libs
(which would be necessary for OpenFL)

> 4) There are no .n files.

Maybe there are deleted after running nekotools?

--
Mockey

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 20:14:16 +0100
Andreas Mokros <m...@medienpensionat.com> wrote:
> with haxe you compile a .n-file (that you can run everywhere)

Everywhere, when neko is installed, that is.

> with xcross you can create a statically linked neko executable for
> win/mac/lin, but I don't know if that exe can also load dynamic libs
> (which would be necessary for OpenFL)

Doesn't seem to work. I made a quick test with nme and the nme.ndll
was not loaded. xcross only seems to load its statically linked files.

nme has the compiled .n file in the /obj-directory BTW. Maybe that's
similar with OpenFL?


Anyway, I found a solution here:
http://blog.lxgcc.net/?tag=dt_runpath
Just needs some linker flags set in the Makefile.

I'll make a pull request.
If you have linux64, I can send you a neko executable for testing.

--
Mockey

[Ashiq A.]

Hi,

Sure, I can test the linux64 version. I assume I just need to back up
my existing neko binaries and put yours in their place.

Thanks for looking into this.

--Ashiq

[Andreas Mokros]

Hi.

On Thu, 26 Feb 2015 16:49:33 -0500
"Ashiq A." <alibha...@gmail.com> wrote:
> Thanks for looking into this.

FYI: I just created an issue on github:
https://github.com/HaxeFoundation/neko/issues/56

--
Mockey

[madneon]

Proper way of getting path of current shell-executable is:

MYPATH=`readlink -f "$0"`
MYPATH=`dirname "$MYPATH"`

as stated in:
http://stackoverflow.com/questions/4774054/reliable-way-for-a-bash-script-to-get-the-full-path-to-itself

Cheers!