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

Hi Monks,

I am using a module which loads a dynamic library to generate SWF output. I had managed to set this up and get it to work on a site I was using it on. I set up a blib like subdirectory in the cgi-bin I was using (I don't have root privileges) and use the BEGIN block to push that directory and the subdirectorys lib and arch into the @INC variable.

This worked,including the ability to load the SWF.so library from ~/cgi-bin/blib/arch/auto/SWF/ the site was merrily generating swf output and I walk away dusting my hands and think okay all is fine.

But today I look up the site and I get the message: 

[Wed Apr 10 16:07:09 2002] SWF.pm:
[Wed Apr 10 16:07:09 2002] DynaLoader.pm: Can't load '/home/zip/54/gal
+482/cgi-bin/blib/arch//auto/SWF/SWF.so' for module SWF: /home/zip/54/
+gal482/cgi-bin/blib/arch//auto/SWF/SWF.so: undefined symbol: PL_sv_un
+def at /usr/lib/perl5/5.004/i386-linux/DynaLoader.pm line 169.
[Wed Apr 10 16:07:09 2002] SWF.pm:
[Wed Apr 10 16:07:09 2002] DynaLoader.pm:
[Wed Apr 10 16:07:09 2002] SWF.pm:
[Wed Apr 10 16:07:09 2002] DynaLoader.pm: at 482.pl line 14 BEGIN fail
+ed--compilation aborted at 482.pl line 14.

[download]
Horror of horrors Dynaloader CAN'T load the module!!!!!!

Hmmm....I would need some advice it seems,

what are the possible causes?

Chris

Edit by tye

Replies are listed 'Best First'.
Re: DynaLoader and PL_sv_undef...
by mpeppler (Vicar) on Apr 10, 2002 at 07:12 UTC
    Your module wasn't built with the same copy of perl that you have on that box (or that is in your path), or the module expects to be built with a newer version of perl (5.005 or later).

    You can fix this by adding something like: 

    #define PL_sv_undef sv_undef

    [download]
    to the .xs module and then rebuilding.

    alternatively - upgrade perl :-)

    Michael

[reply]
[d/l]
Re: DynaLoader and PL_sv_undef...
by MZSanford (Curate) on Apr 10, 2002 at 10:24 UTC
    Per the reply i got to this node, i suggest re-running the build with the POLLUTE=1 option, like :
    $ perl Makefile.PL POLLUTE=1

    [download]
    from the frivolous to the serious
[reply]
[d/l]
[select]
      Thanks for the above advice. I had rebuilt the modules I was using.

      The thing I don't get is why the installation I had made worked in the first place (unless something about the environment changed between the time of installation and yesterday).

      I am using XML::Twig as one of the modules and conveniently enought XML::Parser allows you to build with a local installation of the expat library. However the interesting thing I am encountering now is a message about what I assume is deferencing, disallowing the use of $digit in this case $1.

      I haven't had this sort of trouble on servers running more recent installations of perl so I am sending polite emails to its administrators telling them to update their perl installation (Currently runs 5.004_5 on debian, I don't know whether mod_perl is installed).
      If worse comes to worse I was thinking of persuading my client to change their account to one of the hosts I use.

      Then I got to thinking, it's probably not a good idea, but with all of this tainting of environment variables that people have been doing, it is a possibility to create my own installation of perl at the version I require in the user's directory. This also depends on the amount of space allocated for the account. Tell me are these just the thoughts of an over caffienated, sleep deprived maniac....

[reply]

Back to Seekers of Perl Wisdom