Private modules on webhost - @INC with XS modules?

meyeaard has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks!

I've been using Perl for quite a while now, but today I've come up against a problem I can't budge.

While most of the code I write is for a intranet environment where I have full control over the Perl environment I'm also writing code that is hosted on a shared web server where I am very limited to just the most basic modules the provider has thought to install.

What I have done thus far is to copy my modules to a protected location on my webspace and 'use lib './module-path' to push them into the @INC array - up until now this has worked for the few modules I required.

The problem: I have a program that I need to host on this server that requires the CGI::Application framework and while I was able to get the basic bits of this to work with my previous workaround the modules that use XS code don't work. The interpreter can locate the pm files but doesn't know the location of the .so library files.

So - simply, how does one tell the Perl interpreter to look elsewhere besides the default location for the XS .so library files?

I have asked if they would install additional modules and the answer is stout 'NO'. Also of note, the Perl version there is 5.6.1 and there is no 'blib' module (that came out in 5.8.x didn't it?)

Comment on Private modules on webhost - @INC with XS modules?

Replies are listed 'Best First'.
Re: Private modules on webhost - @INC with XS modules? by Joost (Canon) on Jan 08, 2007 at 23:02 UTC
IIRC you can `use lib 'SOMEWHERE'` as long as you have the XS parts in SOMEWHERE/arch/.... (i.e. SOMEWHERE/arch/auto/Module/Name.so) I don't think "use blib" does anything more than search for a "blib" directory up the tree and "use lib" that. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l]
Re: Private modules on webhost - @INC with XS modules? by chromatic (Archbishop) on Jan 09, 2007 at 00:33 UTC
blib was in Perl 5.6.1 for certain. Your provider's installation is severely broken: `$ perl -MModule::CoreList print Module::CoreList->first_release('blib'); 5.004` [download]	[reply] [d/l]
Re: Private modules on webhost - @INC with XS modules? by rinceWind (Monsignor) on Jan 09, 2007 at 11:25 UTC
Consider using PAR for your application. Either upload a .par file containing the required collection of modules, or go the whole hog and build an executable for your CGI. In either case, you should be able to verify that your app works before you upload it. An alternative is to `make install` to a private directory tree of your own (`perl Makefile.PL PREFIX=/my/dir LIB=/my/dir/lib`), and put this directory tree into your webspace, adding its lib directory to @INC with `use lib`. This will ensure that the binaries are in the right architecture specific directories. -- Oh Lord, won’t you burn me a Knoppix CD ? My friends all rate Windows, I must disagree. Your powers of persuasion will set them all free, So oh Lord, won’t you burn me a Knoppix CD ? (Missquoting Janis Joplin)	[reply] [d/l] [select]
Re: Private modules on webhost - @INC with XS modules? by kwaping (Priest) on Jan 09, 2007 at 16:19 UTC
Try adding your desired shared library locations to the LD_LIBRARY_PATH environmental variable, either in your execution environment or in your individual scripts. --- It's all fine and dandy until someone has to look at the code.	[reply]
Re: Private modules on webhost - @INC with XS modules? by meyeaard (Novice) on Jan 09, 2007 at 21:17 UTC
Thank you for all your replies! I think I have a solution. I'm uploading a full installation of perl 5.6.2 on the website so I can use CPAN to mangage my private modules (I have SSH access) and ensure they are located properly. (I wish I could do this and use 5.8.x but their webserver rewrites all perl scripts to use their interpreter) This way I can just use use lib 'mod-path' to over-ride the default lib paths in my scripts maintaining binary compatibility. I can't believe their perl environment, I found that half of the @INC library paths are invalid and there are duplicate copies of modules scattered through the others... highly thinking of overriding all of @INC since I now have the full dist.	[reply]