Now this is a tale of woe that I've fully experienced. My hosting wouldn't give me shell access and wouldn't install additional modules for me, both due to "security". Ignoring their reasoning I grabbed and extracted tarballs of sources on my local windows machine, uploaded them and tried to run the standard perl Makefile.PL/make/make install routine. Well, almost worked. I could run make (the command, not the step), but the hosting service blocked access to gcc. It's shared hosting, and compiling takes lots of CPU time, so I guess I might be able to see this ...
Next possibility was to compile them on my local linux box. Both it and the target server were x86, no problem, right? I run debian with a 2.6 kernel and perl 5.8, whereas the server ran redhat 7 with a 2.4 kernel and perl 5.6. No, binaries were not compatible.
Last, armed with the server specs, I searched the internet for rpm's of the modules I needed that were as close as I could get to the versions the host ran. I couldn't match the exact redhat version, but I could always find something in the same 7.x chain. I extracted the rpms for all the modules I needed and uploaded them, used lib and was well on my way.
The only last wrench in it all was one of my pre-req's was a Date:: module that had an
optional XS component. Docs say it was supposed to work without it, albeit slower. Well, it refused to run without it, so I found another rpm and everything's been working just peachy for six months now.
The moral of the story: you can nearly always get stuff done, even with stubborn hosting, it just takes a little (lot) more effort.
- Andrew
Text::Highlight - A language-neutral syntax highlighting module in Perl
also on
SourceForge including
demo