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/

[...]

I'm not sure if you shared what kind of system you have, but i'm assuming
it's some kind of Unix, since you're talking about .so and not .dll.

(Most) Unixes search for .so files using the LD_LIBRARY_PATH variable. This
is an environment variable that has the same syntax as PATH. (REMEMBER TO
EXPORT IT !) Make sure that the directories which contain .so files you need
are listed there.

This variable has to be set in the environment of the process that runs Perl.
If this is a Web server (for a CGI script), you may have to modify the shell
script that starts the Web server, or create a shell script to set+export the
variable and start the server.

This variable (or equivalent) is usually documented in the "man pages" for
the "ld" command.

good luck,

g

--
Glauber Ribeiro

"Opinions stated are my own and not representative of Experian"

Sent via Deja.com
http://www.deja.com/

the

Right, it's freebsd

I don't know about exporting environmental variables.

I am attempting to install DBI-1.14 to my local directory because I
don't have root privileges on the shell account server, and basically I
have no privileges on the web server computer.  Everything I know about
or do on that computer (webster) is done through eight CGI commands or
with server-side-includes using the
   <!--#exec cmd="ls /usr/local/perl"-->
format--which means only such commands that can be executed by
user 'nobody' are available.  I think that rules out messing with any
environmental variables or shell scripts that *invoke* Apache.

Thanks, I looked at ld and it did talk abit about magic numbers, so
probably that is the right way to go.  I'll have to ask the admins to
do it though unless there's another workaround.

Sent via Deja.com
http://www.deja.com/