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

Hey guys, upon adding the module Log::Log4Perl to my perl program, I am receiving the following compile-time error. Any idea what this is about ?
ld.so.1: perl: fatal: relocation error: file /opt/edenv/perl/sun4-sola +ris/auto/Time/HiRes/HiRes.so: symbol perl_get_sv: referenced symbol n +ot found Killed

Replies are listed 'Best First'.
Re: Relocation error when using Log::Log4Perl
by marto (Cardinal) on Nov 27, 2006 at 15:35 UTC
    Greetings Anonymous Monk,

    I remember reading someting in the README.solaris file that may be of interest to you:

    "...If you get this message on SunOS or Solaris, and you're using gcc, it's probably the GNU as or GNU ld problem in the previous item "GNU as and GNU ld"..."

    So I think you should have a read at the README.solaris file.

    Hope this helps

    Martin

    Update: Fixed link to README.solaris
Re: Relocation error when using Log::Log4Perl
by chargrill (Parson) on Nov 27, 2006 at 16:44 UTC

    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($,,$;,$*,$/)

      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

        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).