I really would like to understand why I get the warning on this machine but not on the other...
The warning (probably harmless) is simple to explain, ExtUtils::Liblist issues it because it doesn't know where to find those libraries (the ....so)
The error (can't load) is because of those gtk .so's not being found in LD_LIBRARY_PATH or other hardcoded path
| [reply] |
I know where the warning comes from.
What I would like to understand is why on two very similar machines ExtUtils::Liblist knows where to find the libs on one but not on the other. And Glib builds fine on one but not on the other.
Do you have any idea on how to attack this systematically?
As far as perl is concerned the difference between the two machines is that one is 5.14.1 compiled from the source-tarball and the other is 5.16.2 installed via perlbrew.
LD_LIBRARY_PATH is emtpy in both cases.
| [reply] |
What I would like to understand is why on two very similar machines ExtUtils::Liblist knows where to find the libs on one but not on the other. And Glib builds fine on one but not on the other.
Really?
UTSL :)
Same version of liblist? Same ENV vars (like LIB... and what not)?
Do you have any idea on how to attack this systematically?
I linked to it, but here you go
each process comes with cwd/%ENV/@ARGV/STDIN/STDOUT/STDERR ... so compare all paths, all %ENV, all pkg-config/ldconfig ... permissions, etc
What I'm trying to figure is what element of that would cause the script to fail in cron on one server but not the other. My feeling is that it's the database client. The error message is supposed to tell you that :) No error message? Adjust cron error reporting, check your mail, ... Still no error message? Increase verbosity (maybe use Carp::Always; or twiddle some logging levels or $DEBUG++/$VERBOSE++, whatever you're using Still no error message? Maybe redirect errors to a logfile ? Once you have an error message, you can check the usual (everything, sanity check), $PATH/$LD_LIBRARY_PATH..., chroot jail,selinux, permissions and password typos, shebang ... its a checklist, error message usually tells you what to check Like the deep links from Re: Cron revisited/Re^2: Perl Module Not Working In Crontab explain, and here they are:
| [reply] |
<meta http-equiv="Content-type" content="text/html;charset=cswindows1252">
Do you have any idea on how to attack this systematically?
Well, no. I think that your conclusions about the malfunction are incomplete. You could visit
this newer node
and see if that does not provide some insight.
I've just built Glib.pm on MS Whyyndwoes, a tougher platform in general
when it comes to getting such things right; I did so in order to test the build
procedures used by Glib.pm. The insights gained from doing this are written up in
the node mentioned above.
| [reply] |