Earlier, I wrote: > I modified test() to:
> static value test() {
> val_print(alloc_string("Calling a function inside std library...\n"));
> printf("val_null is %p\n", val_null);
> return val_null;
> }
> and got:
> C:\Dev\neko\neko-1.1-src\bin>nekovm.exe test.n
> The virtual machine is working !
> Calling a function inside std library...
> val_null is 00000000
> Called from tools/test.neko line 3
> Uncaught exception - [EMAIL PROTECTED]
> So it appears to be a dynamic linking problem with the datum val_null.
> There is special magic required with gcc to dynamically link against
> data in DLLs. I will try to experiment with this over the weekend.
It appears that the Makefile was not prepared for DLL linkage, but the
source code was ready. I had modified the Makefile CFLAGS to include
-DNEKO_SOURCES but this made everything an export since all libraries
are built with the same Makefile. Reverting CFLAGS and adding
targets for all the libneko files fixed things, e.g.,
vm/alloc.o: vm/alloc.c
${CC} ${CFLAGS} -DNEKO_SOURCES -c $< -o $@
Makefile.diff is attached -- it is suitable for MinGW, it could be
made even more target configurable
I also had to change a couple instances of _WIN32 to _MSC_VER
--- vm\main~.c Tue Nov 8 03:32:26 2005
+++ vm\main.c Thu Nov 10 23:02:26 2005
@@ -54,7 +54,7 @@
return 0;
}
-#ifdef _WIN32
+#ifdef _MSC_VER
# include <crtdbg.h>
#else
# define _CrtSetDbgFlag(x)
--- vm\neko~.h Tue Nov 8 03:32:26 2005
+++ vm\neko.h Thu Nov 10 22:24:05 2005
@@ -22,7 +22,7 @@
#define _NEKO_H
#include <stddef.h>
-#ifndef _WIN32
+#ifndef _MSC_VER
# include <stdint.h>
#endif
Now Neko builds with MinGW/MSYS on WinXP.
e
Makefile.diff
Description: Binary data
--- Neko : One VM to run them all
