# [email protected] / 2010-02-11 08:47:16 +0100:
> Roman Neuhauser a écrit :
> > I'm having trouble with nekoml on FreeBSD 9.0-CURRENT.
> >
> > nekoml runs fine from my usual interactive shell (zsh), but fails
> > with "Uncaught exception - load.c(176): Module not found : ..." when
> > run from /bin/sh.
[...]
> > The environment is the same in my interactive shell and the wrapper.
> > Maybe nekoml does something out-of-ordinary with file descriptors?
> > I'm out of my league here.
>
> nekoml is actually the neko binary on which we append the nekoml
> compiler bytecode. So such bootable binaries need to be able to open
> themself to check if there is bytecode at the end of the file.
>
> This is done by neko/vm/main.c(executable_path) which reads
> /proc/self/exe, and if not found use the "_" environment variable. It
> seems that in some cases both fail to give /usr/bin/nekoml on FreeBSD.
>
> If you know any good way to easily know the current executable path on
> *BSD (and not the calling executable path) I'm open for patches. Both
> windows and OSX have OS-specific functions already.
Great help, thanks! I was able to build hss with this trivial change
applied to neko-1.8.1:
--- vm/main.c.orig 2010-02-12 11:35:23.000000000 +0100
+++ vm/main.c 2010-02-12 11:35:29.000000000 +0100
@@ -59,7 +59,7 @@
return path;
#else
static char path[200];
- int length = readlink("/proc/self/exe", path, sizeof(path));
+ int length = readlink("/proc/curproc/file", path, sizeof(path));
if( length < 0 || length >= 200 ) {
char *p = getenv(" "); // for upx
if( p == NULL )
However, procfs isn't mounted by default (and I have it only on my
notebook, another two or three machines get away without it).
Also, it appears $_ is not standard either; I couldn't find a mention
in SUSv3[1]. Aha, it's a bashism. bash(1), section ENVIRONMENT:
When bash invokes an external command, the variable _ is set to
the full file name of the command and passed to that command in
its environment.
zsh probably has it for compatibility.
All in all it seems it would be better if nekoml either didn't embed
the bytecode or hardwired its own path (that would mean you couldn't
move the binary somewhere else, but that's quite an unusual requirement
(might be different in MS Windows, what with all the "portable apps").
If the bytecode were in a separate file, nekoml might hardwire it's
absolute path, look for it in standard location(s), etc. The procfs
hack wouldn't be needed either.
But I'm sure you have good reasons to embed the bytecode; could you
please rehash them so I know which way to push this further?
[1] http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html
--
Roman Neuhauser
--
Neko : One VM to run them all
(http://nekovm.org)
