On Aug-21, Mattia Barbon wrote: > > Hello, > as promised with this patch: > > pmc2c2 ... --library foo --c pmc1.pmc pmc2.pmc pmc3.pmc ... > > outputs pmcX.c and pmc_pmcX.h as it did before, plus > foo.c and pmc_foo.h containig a single Parrot_lib_foo_load > that initialized vtables and MMD dispatch for all the PMCs, > taking into account circular PMC dependencies in MMD dispatch.
I am trying to use this facility right now, and am encountering problems. For a detailed blow-by-blow account of what I'm doing, see http://0xdeadbeef.net/wiki/wiki.pl?FinkBlog/SharedLibraryHell But that's much too verbose, so I'll just describe the problem. I have two PMCs that need to know about each other, match.pmc and matchrange.pmc. (Ok, actually just one needs to know about the other, but whatever.) So I bound them together into a library 'match_group' using your --library flag. But the resulting shared library uses symbols defined in its constituents, and so when parrot tries to load it, it cannot resolve those symbols. I can fix this by changing the link line that builds match_group.so to explicitly list match.so and matchrange.so, and that enters them in as NEEDED in the shared library match_group.so. So far so good. But then I still can't get it to work, because parrot is only able to find match_group.so because it explicitly constructs the path runtime/parrot/dynext/LIBRARY.so; when dlopen internally tries to load match.so, it doesn't have that path in its RPATH. This is fixable by adding the path to LD_LIBRARY_PATH, but if you're going to do that then why bother with the explicit path construction within parrot? It seems to me that we need to either add the full RPATH to the parrot binary, or teach parrot its absolute path so it can add it at runtime. And I'm not totally sure that the runtime approach will work. Or we could punt and wrap everything for a PMC library into the same .so. But that doesn't seem very nice. How does perl5 handle this? Also, it seems that dynclasses/Makefile has a few gmake-isms thrown in, which I imagine nobody has complained about because the shared library stuff probably only works on Linux anyway right now. (And in my local version, I added lots more to get the match_group.so linked up correctly.)
