On 1/5/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > Nick Glencross wrote: > > The first patch modifies the parrot VM so as not to call > > parrot_get_config_string on startup, which currently resides in the > > calling executable. Instead, the executable (optionally) calls > > Parrot_set_config_hash to set the config environment. > > Looks good.
Thanks. As an aside, I noticed that Darwin was initially a bit funny about this yesterday, but managed to overcome it with a linker flag. > A couple of questions arise: > > <snip...> > > > * The function call parrot_get_config_hash is shared between the > > *_config.o object files and the calling executable (but *not* the VM > > itself). What's the most suitable header file to declare it in? > > There should be just one API call ... > > Parrot_set_config_hash (interpreter); > > ... which calls parrot_get_config_* [1], the prototype should be in > embed.h. Ah, but that's reverting it back to how it was, as the parrot VM is calling back out again to a function in user code. I certainly considered having the *_config.c files continue to return the config bytes, but this felt nicer to me. How about I meet you half way: * The *_config.c files give access to the config bytes * The harness calls the VM with the bytes (which can now be done before the interpreter starts up) * The VM records a pointer to the bytes (and length) * When an interpreter starts, it can either create its own hash, or refer to one hanging off another interpreter (whichever model ends up being used) > Since (as far as I'm aware) cygwin doesn't have rpath > > functionality, it is necessary to add blib/lib to the PATH for it to > > find the parrot DLL. > > Or set LD_LIBRARY_PATH ? LD_LIBRARY_PATH is used by dlopen, but not for DLLs that you are directly linked against by the looks of it. I'll cut another patch when I've made some changes... Nick
