
local install of '.so' modules
I use perl from time to time, and I like to use perl modules which i
must
install locally. I have had trouble with modules that employ c
extensions
such as GD.pm and DBI.pm. They run from the command line (you can
actually supply variables to the script via cgi.pm) just fine and the
extensions are dynamically loaded and everything works. But the modules
fail to load when the cgi is activated from a web browser, returning a
'bad magic number in .... .so' error in the error log. The '.so' files
are the shared object files that represent the C code. Attempts to run
GD.pm last year returned 'undefined symbol' errors. So basically, the
dynamic linking is failing.
Now it is time to consider my ISP's configuration. I believe 'Webster'
runs the Apache server, while my cgi files reside on 'mirage.' My
cgi-bin directory, which is accessible from a shell account on Mirage,
is mapped or mounted or whatever so that it can be read from, written
to, and executed from by Webster. When the
browser requests one of my cgi files like 'dbi_test.cgi,' the version of
perl that is activated is the one that resides on Webster, not Mirage.
As
it happens, the Webster version of perl is version 5.005_02, while on
Mirage Perl is version 5.005_03. Now consider that when DBI-1.14 was
installed, it was compiled using the perl that's on Mirage, 5.005_03.
But
when I try to run 'dbi_test.cgi' from the web browser, the older
version,
5.005_02, is activated and DynaLoader.pm on Webster tries to dynamically
load the relevant libraries. I believe that somewhere here there is a
fatal problem that prevents use of any modules with c extensions that
need
to be loaded via DynaLoader.pm.
This would explain why cgi files that use modules with c extensions run
from the command line but not the browser -- when they are run from the
command line, it's the same version of perl that created them being
used. And if that turns out to be irrelevant, it may be that what is
important is that it's perl on the same machine on which the cgi file
resides that is running. There may not be anything to be done if the
latter is the case, but if it is the former then updating perl on
Webster
will allow people to use perl modules with c extensions.
I have attempted a few workarounds to no avail, such as creating a perl
executable in my cgi-bin directory using the make \ make perl commands
to
the Makefile in DBI-1.14, but this requires ExtUtils/Miniperl.pm, which
is
not present on Mirage at /usr/libdata/perl/5.00503/ExtUtils. Since this
file is generated on the fly when Perl is installed, I cannot simply
place
another version locally. I have also attempted to induce the Webster
version of perl to install the DBI module using a cgi with exec(),
system() and backticks, none of which worked (probably the system won't
allow user 'nobody' to do a perl Makefile.PL command). Finally, I have
looked for a way to perhaps alter the #! line to cause the script as
read
by Apache to invoke Mirage's version of perl rather than Webster's, but
I
think this is impossible -- I didn't find anything.
What is wrong here? I thought I'd post here before asking the admin to
install DBI on the webserver. Any insight would be greatly appreciated.
Ken Truitt
Here's the error message (i change the order of modules, and it's
always the first one with an '.so' file that aborts compilation of the
script):
[Tue Jan 23 16:15:07 2001] CSV.pm: [Tue Jan 23 16:15:07 2001] CSV.pm:
[Tue Jan 23 16:15:07 2001] CSV_XS.pm: [Tue Jan 23 16:15:07 2001]
CSV_XS.pm: Can't load '/var/spool/www2/infomud.com/cgi-
bin/lib/perl5/site_perl/i386-freebsd/auto/Text/CSV_XS/CSV_XS.so' for
module Text::CSV_XS: bad magic number
in "/var/spool/www2/infomud.com/cgi-bin/lib/perl5/site_perl/i386-
freebsd/auto/Text/CSV_XS/CSV_XS.so"
at /usr/local/lib/perl5/5.00502/i386-freebsd/DynaLoader.pm line 168.
[Tue Jan 23 16:15:07 2001] CSV.pm: [Tue Jan 23 16:15:07 2001] CSV.pm:
[Tue Jan 23 16:15:07 2001] CSV_XS.pm: [Tue Jan 23 16:15:07 2001]
CSV_XS.pm: [Tue Jan 23 16:15:07 2001] CSV.pm: [Tue Jan 23 16:15:07
2001] CSV.pm: [Tue Jan 23 16:15:07 2001] CSV_XS.pm: [Tue Jan 23
16:15:07 2001] CSV_XS.pm: at /var/spool/www2/infomud.com/cgi-
bin/lib/perl5/site_perl/DBD/CSV.pm line 47 [Tue Jan 23 16:15:07 2001]
CSV.pm: [Tue Jan 23 16:15:07 2001] CSV.pm: BEGIN failed--compilation
aborted at /var/spool/www2/infomud.com/cgi-
bin/lib/perl5/site_perl/DBD/CSV.pm line 47. BEGIN failed--compilation
aborted at /www/virtual/infomud.com/cgi-bin/dbi_test.cgi line 8.
Sent via Deja.com
http://www.*-*-*.com/