Imagine a large third-party database app. Let's call it "MYAPP". It's implemented primarily as shared libraries (or DLL's on Windows). Now, imagine someone has written an XS binding to it; we'll call this "MYXS". And we'll stipulate that it works fine.
Now the problem: MYAPP must be installed locally (per-host) as it digs deep into the kernel etc. Perl is ideally and typically installed in a network location such as /usr/local/... or \\fileserver\perl5\.... This becomes a potential problem because the MYXS shared object is compiled against whatever version of MYAPP is installed on the build platform and may not work with other versions. I.e. if there are hosts running MYAPP 2.x, 3.x, and 4.x around your network you can build MYXS to work with one of those versions but not all, given that there's just one physical copy of the .so file. Does anyone know of a solution to this? Preferably something clean and Perl-ish, as opposed to hacking MYXS into the MYAPP install script and modifying PERL5LIB to point to the local copy or whatever. I'd like to think there's an advanced DynaLoader mechanism I haven't heard about that would let the module author provide rules determining which MYXS.xx.so to load, where "xx" represents the version of MYAPP. Thanks, David Boyce
