Unusual Can't load fail (web only) 
Author Message
 Unusual Can't load fail (web only)

Hi all,

I've got an odd problem, that doesn't seem to be covered by any of the
exisiting threads. When I run a simple DB perl script through the
command line, it fetches the info and works fine. However, if I run it
via the web, I get the following error:

install_driver(mysql) failed: Can't load
'/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysql.so'
for module DBD::mysql:
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysql.so:
undefined symbol: PL_perl_destruct_level at
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.

I've re-installed DBD::mysql using perl -MCPAN -e shell; and manually,
and there's no change. The fact that it runs via command line seems to
indicate permissions, but I ran "chmod -R o+r /usr/lib/perl5" and no
change.

Any help would be appreciated.

Thanks!



Tue, 22 Nov 2005 18:25:38 GMT  
 Unusual Can't load fail (web only)

Quote:

> Hi all,

> I've got an odd problem, that doesn't seem to be covered by any of the
> exisiting threads. When I run a simple DB perl script through the
> command line, it fetches the info and works fine. However, if I run it
> via the web, I get the following error:

> install_driver(mysql) failed: Can't load
> '/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysql.so'
> for module DBD::mysql:
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysql.so:
> undefined symbol: PL_perl_destruct_level at
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.

> I've re-installed DBD::mysql using perl -MCPAN -e shell; and manually,
> and there's no change. The fact that it runs via command line seems to
> indicate permissions, but I ran "chmod -R o+r /usr/lib/perl5" and no
> change.

> Any help would be appreciated.

> Thanks!

Just a thought, double check the shebang line at the top of the perl
main executable.

#! /usr/bin/perl

And then run perl -v from the command line to make sure everything is
pointing to the same place.

hth,

s.



Tue, 22 Nov 2005 20:28:18 GMT  
 Unusual Can't load fail (web only)

<snip>

Quote:
> install_driver(mysql) failed: Can't load

'/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mys
ql.so'
Quote:
> for module DBD::mysql:

/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysq
l.so:

The error that the '.so' file "can't be loaded" indicates that the '.pm'
file has been found (no problem there) and that the '.so' file was *found*,
but can't be loaded - which must surely be a permissions issue, given that
there's no such problem from the command line. Something to do with
'executability' perhaps ??

Cheers,
Rob



Wed, 23 Nov 2005 02:10:58 GMT  
 Unusual Can't load fail (web only)

Quote:
> Hi all,

> I've got an odd problem, that doesn't seem to be covered by any of the
> exisiting threads. When I run a simple DB perl script through the
> command line, it fetches the info and works fine. However, if I run it
> via the web, I get the following error:

> install_driver(mysql) failed: Can't load
> '/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread
> multi/auto/DBD/mysql/mysql.so' for module DBD::mysql:
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-
> multi/auto/DBD/mysql/mysql.so:
> undefined symbol: PL_perl_destruct_level at
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.

> I've re-installed DBD::mysql using perl -MCPAN -e shell; and manually,
> and there's no change. The fact that it runs via command line seems to
> indicate permissions, but I ran "chmod -R o+r /usr/lib/perl5" and no
> change.

> Any help would be appreciated.

> Thanks!

The PL_perl_destruct_level symbol should be coming from
your perl lib. I would have thought though this would have been
picked up in building and testing DBD::mysql, but you say there
was no problem there ... Might there be multiple DBD::mysql
installations, and your web script is picking the wrong one? Does
setting within the web script the environment variable
LD_LIBRARY_PATH, pointing to where libraries live, help?

best regards,
randy kobes



Wed, 23 Nov 2005 07:19:26 GMT  
 Unusual Can't load fail (web only)

Quote:
> The PL_perl_destruct_level symbol should be coming from
> your perl lib. I would have thought though this would have been
> picked up in building and testing DBD::mysql, but you say there
> was no problem there ... Might there be multiple DBD::mysql
> installations, and your web script is picking the wrong one? Does
> setting within the web script the environment variable
> LD_LIBRARY_PATH, pointing to where libraries live, help?

This looks like the most likely situation... Turns out my LD_LIBRARY_PATH
appears to be null!

I'm running RedHat 9, so I've added a definition to /etc/profile, and added
"PassEnv LD_LIBRARY_PATH" to my httpd.conf.

Does that sound right, or am I on the wrong track?

Thanks



Wed, 23 Nov 2005 14:40:44 GMT  
 Unusual Can't load fail (web only)

Quote:
> > The PL_perl_destruct_level symbol should be coming from
> > your perl lib. I would have thought though this would have been
> > picked up in building and testing DBD::mysql, but you say there
> > was no problem there ... Might there be multiple DBD::mysql
> > installations, and your web script is picking the wrong one? Does
> > setting within the web script the environment variable
> > LD_LIBRARY_PATH, pointing to where libraries live, help?

> This looks like the most likely situation... Turns out my LD_LIBRARY_PATH
> appears to be null!

> I'm running RedHat 9, so I've added a definition to /etc/profile, and
added
> "PassEnv LD_LIBRARY_PATH" to my httpd.conf.

> Does that sound right, or am I on the wrong track?

It might help if it's a problem in finding and loading shared
libraries, but I'd suggest checking first if there's multiple
DBD::mysql installations on your system. The original error
message referred to a problem with something under
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/ -
is this where DBD::mysql was installed when you built it
yourself (and presumably were using when the script was
run from the command line)?

best regards,
randy



Wed, 23 Nov 2005 17:31:35 GMT  
 Unusual Can't load fail (web only)


Quote:
> > Does that sound right, or am I on the wrong track?

> It might help if it's a problem in finding and loading shared
> libraries

I don't think that there's a problem in *finding* the shared libs. If there
was such a problem then the error message should start with "Can't locate
loadable object..." , not "Can't load...".

Cheers,
Rob



Thu, 24 Nov 2005 01:55:46 GMT  
 Unusual Can't load fail (web only)

Quote:

> > > Does that sound right, or am I on the wrong track?

> > It might help if it's a problem in finding and loading shared
> > libraries

> I don't think that there's a problem in *finding* the shared libs. If
there
> was such a problem then the error message should start with
> "Can't locate loadable object..." , not "Can't load...".

I'm just guessing here, but if it was a problem in loading a
shared external library (not a Perl one), then one could get
a message about not being able to locate a loadable object ...
For example, (on Win32) I built XML::LibXML against a dynamic
libxml2 library, and if I hide that libxml2.dll (and keep all the Perl
files in place) and use XML::LibXML, then I get a message

Can't load '/Path/to/XML/LibXML/Common/Common.dll' for
module XML::LibXML::Common: load_file: The specified module
could not be found at /Path/to/Dynaloader.pm
at /Path/to/XML/LibXML.pm

You're right if it was a problem in finding a Perl lib - for example,
if I hide the Perl lib /Path/to/XML/LibXML/Common/Common.dll,
then trying to use XML::LibXML results in a message

Can't locate loadable object for module XML::LibXML::Common ...

best regards,
randy



Thu, 24 Nov 2005 05:22:21 GMT  
 Unusual Can't load fail (web only)


Quote:

> > I don't think that there's a problem in *finding* the shared libs. If
> there
> > was such a problem then the error message should start with
> > "Can't locate loadable object..." , not "Can't load...".

> I'm just guessing here, but if it was a problem in loading a
> shared external library (not a Perl one), then one could get
> a message about not being able to locate a loadable object ...

I thought that would produce the complaint that the perl lib (which needs
that unfindable shared external library) could not be *loaded* - as per your
example immediately below.

Quote:
> For example, (on Win32) I built XML::LibXML against a dynamic
> libxml2 library, and if I hide that libxml2.dll (and keep all the Perl
> files in place) and use XML::LibXML, then I get a message

> Can't load '/Path/to/XML/LibXML/Common/Common.dll' for
> module XML::LibXML::Common: load_file: The specified module
> could not be found at /Path/to/Dynaloader.pm
> at /Path/to/XML/LibXML.pm

Yep - I follow .... and agree.

Quote:
> You're right if it was a problem in finding a Perl lib - for example,
> if I hide the Perl lib /Path/to/XML/LibXML/Common/Common.dll,
> then trying to use XML::LibXML results in a message

> Can't locate loadable object for module XML::LibXML::Common ...

> best regards,
> randy

I think I get your point .... but I don't quite follow the ( first part of
the) elaboration you provided :-)

I believe the error message is complaining that a perl lib, although found,
cannot be loaded.

I think you're saying the reason the perl lib cannot be loaded is (perhaps)
that a requisite external lib cannot be found. And that is quite correct,
afaik.
In such cases, on Win32, you'll get a popup telling you just which external
lib could not be found.

Alternatively the problem could be that the perl lib in question is in some
way unsuitable - as you've previously hinted. (The stuff about " undefined
symbol: PL_perl_destruct_level" seems to me to support this .... but the
fact that the there's no problem from the command line goes against it.)

I'm not a linux person ..... should probably just shut up :-)

Cheers,
Rob



Thu, 24 Nov 2005 06:13:14 GMT  
 Unusual Can't load fail (web only)

Quote:


> > > I don't think that there's a problem in *finding* the shared libs. If
> > there
> > > was such a problem then the error message should start with
> > > "Can't locate loadable object..." , not "Can't load...".

> > I'm just guessing here, but if it was a problem in loading a
> > shared external library (not a Perl one), then one could get
> > a message about not being able to locate a loadable object ...

> I thought that would produce the complaint that the perl lib (which needs
> that unfindable shared external library) could not be *loaded* - as per
your
> example immediately below.

You're right - sorry about that; that should have read that one
would get a message about something that cannot be loaded,
in the case of an unfindable shared external lib.
[ .. ]

Quote:
> I think you're saying the reason the perl lib cannot be loaded is
(perhaps)
> that a requisite external lib cannot be found. And that is quite correct,
> afaik. In such cases, on Win32, you'll get a popup telling you just
> which external lib could not be found.

> Alternatively the problem could be that the perl lib in question is in
some
> way unsuitable - as you've previously hinted. (The stuff about " undefined
> symbol: PL_perl_destruct_level" seems to me to support this .... but the
> fact that the there's no problem from the command line goes against it.)

As you're well aware of in the Win32 world :), it can be tricky mixing
and matching binaries (in this case, from rpms). From what I understand,
Mike, the original poster, built DBD::mysql himself, and the script
ran fine from the command line, but not from the web. This may be
due to the web environment not seeing some external libraries that
the command-line environment sees. It might also be that the web
version is using an older DBD::mysql from the Perl rpm - the error
referenced /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/,
whereas CPAN.pm might have installed things under something like
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/.

best regards,
randy



Thu, 24 Nov 2005 06:52:43 GMT  
 Unusual Can't load fail (web only)


Quote:

> As you're well aware of in the Win32 world :), it can be tricky mixing
> and matching binaries (in this case, from rpms). From what I understand,
> Mike, the original poster, built DBD::mysql himself, and the script
> ran fine from the command line, but not from the web. This may be
> due to the web environment not seeing some external libraries that
> the command-line environment sees.

I'd have to agree - that seems more feasible than what I initially
suggested.

Quote:
>It might also be that the web
> version is using an older DBD::mysql from the Perl rpm - the error
> referenced /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/,
> whereas CPAN.pm might have installed things under something like
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/.

Not so sure about that one. Since DBD::mysql bootstraps its $VERSION I would
expect a version mismatch error, rather than a "Can't load ...".
Then again, if the "other" perl lib that is found happens to be the same
version, but is in some way broken, you *could* get the "Can't load ..."
error.

Hmm ... there comes a point where one should cease to speculate, and I think
I may well have reached (or even proceeded beyond) that point :-)

I hope you don't feel that I'm "taking you to task" over this, btw. That's
*not* my intention. It's now become more about checking up on my own
understanding .... which amounts to a hijacking of this thread ... and I
don't want to do that either :-)

Cheers,
Rob



Thu, 24 Nov 2005 21:02:58 GMT  
 Unusual Can't load fail (web only)

Quote:

>This looks like the most likely situation... Turns out my LD_LIBRARY_PATH
>appears to be null!

that's usually fine.

Quote:
>I'm running RedHat 9, so I've added a definition to /etc/profile, and added
>"PassEnv LD_LIBRARY_PATH" to my httpd.conf.

>Does that sound right, or am I on the wrong track?

you probably want to run (as root) ldconfig to add the directories where
your perl libraries and mysql libraries live.

-rs-



Fri, 25 Nov 2005 20:37:37 GMT  
 Unusual Can't load fail (web only)
Thanks for the insight guys, it has given me plenty to chew on. Should have
mentioned that I'm on a RedHat 9 system, sounds like this would all be
easier if it was a problem on Win32. :(

I've kind of been down the "multiple install" road before. When I check for
multiple mysql.so's I get this:

Quote:
>locate mysql.so

/usr/lib/perl5/site_perl/i386-linux/auto/DBD/mysql/mysql.so
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysq
l.so
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBD/mysql/mysql.so

Now, what I've done is make the first 2 symbolic links to the third (which
is where my CPAN install went), and I still get the same reaction. When I
remove the link referred to in the error log
(/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mys
ql.so), I get this:

install_driver(mysql) failed: Can't locate loadable object for module

/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at
(eval 2) line 3

Which makes sense. And to help solve the mystery slightly, when that link is
removed, I can still run the script via the command line. Soooo, the command
line is looking elsewhere, and by process of elimination, that "elsewhere"
is /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBD/mysql/mysql.so.

I've done some tinkering with symbolic links and probably managed just to
break things even more. Anyone know how I can now force my apache web
environment to use the same (I.E. correct) perl lib paths as the command
line?

Thanks



Sat, 26 Nov 2005 14:29:06 GMT  
 Unusual Can't load fail (web only)
"Ralph Snart" wrote

Quote:
> you probably want to run (as root) ldconfig to add the directories where
> your perl libraries and mysql libraries live.

Thanks Ralph, this sounds like it might be the right way to go.
Unfortunately, none of the directories I add to /etc/ld.so.config seem to
actually add any libraries when ldconfig -v is run. Any advice on what to
add?

Thanks



Sat, 26 Nov 2005 15:40:49 GMT  
 Unusual Can't load fail (web only)

Quote:

>Thanks for the insight guys, it has given me plenty to chew on. Should have
>mentioned that I'm on a RedHat 9 system, sounds like this would all be
>easier if it was a problem on Win32. :(

>I've kind of been down the "multiple install" road before. When I check for
>multiple mysql.so's I get this:

>>locate mysql.so
>/usr/lib/perl5/site_perl/i386-linux/auto/DBD/mysql/mysql.so
>/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mysq
>l.so
>/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBD/mysql/mysql.so

>Now, what I've done is make the first 2 symbolic links to the third (which
>is where my CPAN install went), and I still get the same reaction. When I
>remove the link referred to in the error log
>(/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/DBD/mysql/mys
>ql.so), I get this:

>install_driver(mysql) failed: Can't locate loadable object for module

>/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
>/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
>/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
>/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
>/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
>/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at
>(eval 2) line 3

>Which makes sense.

That does make sense - probably the DBD::mysql under
/usr/lib/perl5/vendor_perl/5.8.0/ is looking for the
mysql.so under the same directory, as that's what it
was compiled with.

Quote:
>And to help solve the mystery slightly, when that link is
>removed, I can still run the script via the command line. Soooo, the command
>line is looking elsewhere, and by process of elimination, that "elsewhere"
>is /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBD/mysql/mysql.so.

>I've done some tinkering with symbolic links and probably managed just to
>break things even more. Anyone know how I can now force my apache web
>environment to use the same (I.E. correct) perl lib paths as the command
>line?

It might be a better idea, in principle, not to have two
versions of the same module lying around, just so as to not
run into this problem again. What you might try is going
underneath /usr/lib/perl5/vendor_perl/5.8.0/ and removing
(or, to be safe, moving to some archive elsewhere) all the
DBD-mysql distribution files. To see what's involved, when you
build DBD::mysql from the sources, the files to be installed are
placed under the blib/ directory, in a similar directory
structure to what will be installed.

--
best regards,
randy



Sat, 26 Nov 2005 16:02:35 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Unusual 'use vars' question

2. install_driver(Oracle) failed: Can't load...Oracle.dll

3. Module loading error: Apache can't load Apache::Server

4. Can't load module Tk, dynamic loading not available in this p

5. Dynamic loading failed?

6. Dynamic loading fails - help !

7. DBI module loading fails ...

8. Sendmail::Milter fails under load

9. Apache.pm failed to load

10. Apache.pm failed to load

11. DBI and failed module load

12. DBI and failed module load

 

 
Powered by phpBB® Forum Software