On 2011-02-13, at 9:46 PM, Jason E. Aten wrote:
A quick update and a follow up question. I was able to successfully call into the CUDA code from compiled scheme. (Horray!)
Great!
But now I don't seem to be able to load the object file from the interpreter, even when I start it as gsc.
I even tried renaming my shared object (build with -fPIC) to end in .o1. But still no luck using (load "myobject.o") or (load "myobject.o1").
You cannot rename the .oN files (which are shared object files). The reason is that when you do (load "X.o1") Gambit will call dlopen to dynamically link with X.o1, and then the initialization function "____20_X_2e_o1" (which has been generated by the Gambit-C compiler) will be searched for in that shared object. If you rename foo.o3 to X.o1 the correct initialization function "____20_foo_2e_o3" will not be found because load is looking for "____20_X_2e_o1". The approach of naming the initialization function by mangling the file name is necessary for some operating systems that don't allow, or get confused, when executing dlopen of files containing the same function name.
If you want to give the file a specific name, then use the -o option when creating the link file or dynamically loadable object file. This message may be of help:
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2004-October/000014.h...
Is there a special call to load a shared library into the interpreter?
No. However, you could use the FFI to expose the dlopen function.
Alternatively, is there a way to invoke an interpreter REPL from within a compiled executable?
You can start a repl from a program at any time by calling (##repl-debug) .
Marc