You're right that just being able to load both from the same script and run them serially over the same array would meet my immediate needs.

And in theory, it should be possible to load the same named DLL provided they are in different subdirectories. (Under Windows at least.)

But forcing Perl to (re)invoke the dynaloader would require messing with %INC between requires I think.

Maybe Class::Unload can help here?

Regards, Stefan

Whilst that might work at the Perl level, I think it would fail to resolve the problems that arise from identically named entrypoints in the dlls of XS components.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Ah, I see what you mean :)  Still, I think it wouldn't work, because the dynamic linker would not remap the same .text/.data symbols that have already been mapped upon initial loading of the lib (at least not on Linux/Unix — maybe Windows is different in this regard).

(AFAIK, that very property is being used to hijack certain routines (such as in libc) by LD_PRELOADing some other lib that provides the same routines, so that the ones of the same name supplied in a later loaded lib will be ignored.)

To verify, I just played with this a little, and even by manually fixing the bootstrap version issue you mentioned, clearing various DynaLoader arrays before trying to switch libs

  undef @DynaLoader::dl_modules;
  undef @DynaLoader::dl_shared_objects;
  undef @DynaLoader::dl_librefs;
[download]

and manually loading the shared object file

  DynaLoader::dl_load_file('Devel-Size-0.72/blib/arch/auto/Devel/Size/
+Size.so');
[download]

I was not able to get the total_size() XS routine from 0.72 called.  Even after having loaded the new (0.72) Size.so (and I did check with strace that it was in fact loaded), it was still the 0.71 version (loaded/mapped first) that was being called... As expected.

Anyhow, even if you could get this to work somehow by further messing around with DynaLoader, it would likely not be easier than just using a different namespace.