Well I got it to work, but I don’t understand why the fix worked. A person on the mod_perl list suggested I go over my ‘use’ statements in the mod_perl startup file run when Apache is initialized.
The script worked without errors in mod_perl after adding '/usr/lib64/perl5/vendor_perl’ to my ‘use’ statement in startup.pl, EVEN THOUGH it’s already in @INC (the list below were from before I made this change) , and DBD::mysql itself is located in /usr/local/lib64/perl5/DBD. (Based on Andreas suggestion about libraries I uninstalled the CentOS perl-DBD-MySQL package and then installed it from scratch via cpan so that the installed mariadb client libraries were used to compile it...which by itself didn’t fix the issue) I still don’t know why DBI was throwing that peculiar error about DBD::mysql. Going to put this in my notes, edge slowly away and not mess with it more :-) On Jun 3, 2020, at 10:37 AM, Bruce Johnson <john...@pharmacy.arizona.edu<mailto:john...@pharmacy.arizona.edu>> wrote: On Jun 2, 2020, at 12:30 PM, Andreas Mock <andreas.m...@web.de<mailto:andreas.m...@web.de>> wrote: Hi Bruce, only some hints. It sounds to me like a shared object mess which may be possible after upgrading. It may be something in my mod_perl environment. I constructed a quick test script that queries the user table. #!/usr/bin/perl use strict; use DBI; use lib "/home/allwebfiles/perl/LocalModules"; use PharmApps::AllDefaults qw(PrintHeader); my $dsn = "DBI:mysql:database=mysql;host=localhost;port=3306" ; my $dbh = DBI->connect($dsn, ‘xxxxxx', ‘xxxxxx') or print $DBI::errstr; my $csr= $dbh->prepare("select Host, User from user"); my ($i, $j); $csr->execute(); print PrintHeader; print "<table><tr><th>Host</th><th>User</th></tr>\n"; while (($i, $j) = $csr->fetchrow()){print "<tr><td>$i</td><td>$j</td></tr>\n";} print "</table>\n"; print "<table><tr><th>\@INC</th></tr>\n"; foreach $i (sort @INC){print "<tr><td>$i</td></tr> \n";} print "</table>"; On the command line it works without error. When I altered the settings to run it as a cgi script (ie not with a mod_perl handler) it also works; it appears that the error is only happening in the context of the script running in Apache (with ModPerl enabled.) Host User % pharmacyevents 127.0.0.1 root localhost pharmacyevents localhost root @INC /home/allwebfiles/perl/LocalModules /home/allwebfiles/perl/LocalModules/ /usr/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/share/perl5 /usr/share/perl5/vendor_perl The only difference I can see is that the @INC when it’s running in ModPerl is that two additional paths are included: @INC /etc/httpd <<<< /home/allwebfiles/perl/LocalModules /home/allwebfiles/perl/LocalModules/ /usr/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/vendor_perl/Bundle <<<< /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/share/perl5 /usr/share/perl5/vendor_perl Adding those two paths to @INC (via 'use lib’ statements) doesn’t break the script in CGI mode. Very strange, because I cannot think of any reason that running it under mod_perl would cause a problem with DBI, it doesn’t happen with any other systems I’m running it on. I”m going to take this off to the mod_perl list, I guess. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
