local install of '.so' modules 
Author Message
 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/



Sun, 13 Jul 2003 06:19:21 GMT  
 local install of '.so' modules

Quote:

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

[...]

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/



Sun, 13 Jul 2003 06:42:55 GMT  
 local install of '.so' modules


the

Quote:
> > dynamic linking is failing.
> [...]

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

Right, it's freebsd

Quote:
> (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.

I don't know about exporting environmental variables.

Quote:
> 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.

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.

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

> good luck,

> g
> --
> Glauber Ribeiro

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/



Sun, 13 Jul 2003 08:49:51 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Can't install DBI module to local directory

2. PPM: can't install modules from local directory

3. Can't install Net module using ppm - Can't find module

4. installing modules without 'make'

5. Installing modules without 'make'

6. Trouble installing 'private' versions of modules

7. Installing XML::Parser 'make install error'

8. local var 'feature'/bug ?

9. '#!/usr/local/bin/perl -s' problem

10. Origin of 'local'?

11. 'static' local variables in 5.003

12. Origin of 'local'?

 

 
Powered by phpBB® Forum Software