Hi, Even if perl is installed on a shared server, you can still have locally installed modules. It sounds like this is what you should do - perhaps recompile perl to put a local directory in its @INC.
On Friday, May 31, 2002, at 12:51 AM, David Boyce wrote: > 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 > > -Ken
