On Aug-28, Dan Sugalski wrote: > > We dynamically load libraries. Whee! Yay, us. We need a set of > semantics defined and an API to go with them so we can meaningfully > and reliably work with them.
Hm. Today I was working with the current implementation of this stuff, and uncovered a bunch of questions. I'm not sure this thread is really the right one for my questions, but it was too timely to pass up. > 1) Load the shared library from disk > > The equivalent of dlopen. (May well *be* dlopen) I'm running into problems with loading libraries that are dependent on other (user-provided, not system) libraries. I'm thinking it would be nice to have an interface for setting search paths. Take my particular case: I have something called match_group.so which contains some undefined symbols from both match.so and matchrange.so. All of these are from dynamic PMCs, so they should be found in runtime/parrot/dynext/. And if I run from the top-level directory, match_group.so *is* found -- but it fails to load, because it can't find its dependencies. match_group.so is found because dynext.c:get_path() explicitly looks through runtime/parrot/dynext, but that doesn't help the implicit loading of match.so. I can get it to work by explicitly setting LD_LIBRARY_PATH to the absolute path of the dynext/ directory, but that's not a good long-term solution. So there are two problems. One is that parrot looks in a relative directory when it's searching for dynamic libraries. If this were an absolute path, then you could run parrot from some other directory and still find your libraries, but I don't know if parrot knows where it is running from yet. (FindBin, anyone?) The second problem is that parrot must be able to find dependent libraries implicitly, so it can't manually construct paths and have things work. One solution for this would be to add an API entry to set the search path. On Unix, I think that means setting LD_LIBRARY_PATH, I haven't tried that to see if it actually works if you set it while a program is running -- there were some hints on Google that it might fail. If it doesn't work, I don't know of any other way to set the implicit search path programmatically, so perhaps it shouldn't be in the API. :-) Alternatively, we can hardcode the absolute path to the dynext/ directory in the RPATH tag of the dynamic section (for ELF). > We're also going to want to allow embedding applications to pass in > handles to existing libraries (so, for example, we don't try and load > in half a dozen versions of the expat library...) that it's already > loaded in. I believe glibc already caches all of the handles and just gives you back the same handle if you ask for it again. So unless other systems don't, this isn't needed. I'll write another message specifically talking about the problems I am encountering, because the remainder has no bearing on the API.
