Re: Relocation error when using Log::Log4Perl

I've said it before, and I'll say it again:

Perl modules using XS are notoriously hard to install correctly on solaris, usually because the perl shipped with solaris was built using the sun workshop compiler. As a result, trying to compile XS modules often fails, because most of the time the only compiler around is gcc, which causes a conflict.

--chargrill

s**lil*;  $*=join'',sort split q**;  s;.*;grr; &&s+(.(.)).+$2$1+; $; =
qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
[download]

Comment on Re: Relocation error when using Log::Log4Perl Download Code

Replies are listed 'Best First'.
Re^2: Relocation error when using Log::Log4Perl by clscott (Friar) on Nov 27, 2006 at 18:27 UTC
On any OS that provides a perl you should always compile and maintain your own perl distribution. That way you do not have to worry about OS patches installing updated Perl modules and breaking your applications and vice-versa. I just compile perl into /opt/<company>/perl on a build system. Then I install the modules and make a Solaris package from the install directories. Then this package can be installed into any environment (development, qa, staging and production) and I know that my deployment procedure is testable, repeatable and automatable. On Solaris I tend to create Solaris packages of my perl applications too, so that my deployments go more smoothly. -- Clayton	[reply]
Re^3: Relocation error when using Log::Log4Perl by Fletch (Bishop) on Nov 28, 2006 at 01:10 UTC
Excellent advice. It also isolates you from problems when you have different groups maintaining the OS and the applications, so you don't have the OS admins pushing out a newer perl RPM through `up2date` and managing to clobber all your site installed modules simultaneously . . . (fortunately I didn't have to clean up too much on that one :). At `$cur_job` I try and keep a separate "application" copy of all the really critical underlying software packages (Perl, gcc, PVM, ruby) that's independent of the RPM-installed system copies (granted we have a frelling huge NFS share for this which makes it easier than custom local RPMs; we're dependent on the same NFS mount for sharing gigs of data across n-hundred boxen anyhow so we live with the failure point for the binaries as well).	[reply]