nekotools boot result not standalone, requires ndll

[Jan69]

what's the point of a not-standalone binary if you get the same effect with a 2-line shell script (including the shebang), or similarly short bat file, and a symlink?
IMO it pretty much destroys any point of using nekotools boot since you still require all of the used .ndll files anyway, so why not just use neko binary itself at that point (maybe with a wrapper script if you want a fancy-named program)
to make extra sure, I built neko from source with STATIC_DEPS=all disabling all the configurable features (JIT + WITH_* stuff) leaving it relocatable, thinking that maybe it helps even a tiny bit...

nekotools --help says that boot <file.n> : build an standalone executable, so lets see how true that is...

$ ./nekotools boot test.n
$ cp test /tmp
$ /tmp/test
/tmp/test: error while loading shared libraries: libneko.so.2: cannot open shared object file: No such file or directory

ok understandable, it must be keeping everything in that one library right...

$ cp libneko.so.2 /tmp/
$ /tmp/test
The virtual machine is working !
Calling a function inside std library...
Test successful

so it works? not really, it works only because I was in the directory with the .ndll files...

$ cd /tmp
$ ./test
Uncaught exception - load.c(237) : Failed to load library : std.ndll (std.ndll: cannot open shared object file: No such file or directory)

this is even on the same system, without needing to test it in a chroot or an actually different system, or anything...

of course that's not even touching on the fact that it's dynamically linked to system-specific libraries, which is an unrelated problem for standalone programs, although it's completely normal for stuff installed and used on one system... and there's no option to compile it statically, or even attempt to do that, without manually editing the makefiles or stuff like that...

I love neko, or at least I love what it could be, which is why I've been sad about this since I first found it... I am not skilled enough to fix it myself... unless the solution is removing it altogether...

[tobil4sk]

The problem here was that nekotools boot is not a good/safe way of generating an executable, see #130. With nekotools boot -c, the c source file can be compiled manually using a c compiler, and an -rpath value can be added so that the executable is able to load the ndlls and libneko from the correct location.

[tobil4sk]

I think I misunderstood the original issue, so just to clarify:

It turns out nekotools boot actually does create an executable with a correctly set RUNPATH value. Once neko/nekotools is installed on the system, the nekotools generated executable can load the libneko/ndll from the system library path [0] or from the same directory that the executable is in (i.e. $ORIGIN, assuming -DRELOCATABLE=ON). This is the reason for the libneko.so.2 and std.ndll loading errors, as std.ndll was in neither location.

This means that when distributing the app, libneko.so and the ndlls must be packaged alongside with the app (in the same directory). Dynamic linking and loading is how neko programs have always used ndlls, so static linking is not really an option.

For more control over the runpath, nekotools boot -c should be used instead which allows manually compiling a c file, as mentioned above.

[0] - Non-/usr install prefixes don't work by default until #271 is merged.