I have a Perl application that (has to...) run as a CGI application on a shared host. I have quite an intractible problem here... please read the following description c-a-r-e-f-u-l-l-y and please help me if you can.

1. The program uses DBD::mysql, which has been installed into the local shared-host directories and correctly placed into the @INC array via a use lib statement. All parameters are known-good. Based on the output in a log file from the web-app (when run by Apache...) I know that one of the entries in @INC does point to a location where auto/DBD/mysql/mysql.so can be found, and that it does exist.
2. The program works correctly when run directly from the command-line on the shared host.
3. When run from Apache on the same host, however, the application's log-file contains the following error:
   Quote:

   DBIx::Class::ResultSet::next(): DBI Connection failed: Undefined subroutine &DBD::mysql::db::_login called at /homepages/blah-blah-blah/local-perl/lib/perl/5.8.8/DBD/mysql.pm line 142.

   (This is the correct file-path. And since the message is in the application's logfile, we also know that the application is running.)
4. All of the .so files are executable. r-xr-xr-x.
5. I do not have access to Apache error-log files on this host.
6. When run on an Apache server on my development machine... it works.
7. I have systematically determined that the proper copy of mysql.so is being used on my system, by having temporarily renamed all others.

In other words, here we are dealing with some kind of difference between the Apache CGI environment on the shared-host, and both the command-line environment on that host and the Apache CGI environment on my box. This is why I call the problem "intractible," and by now I am quite desperate for a solution.

Thinking of things that can be different between the Apache and Bash environment, I can think of a couple of possibilities. Firstly, when run as a child of the Apache server, the UID will be that of the Apache server. File permissions and the likes of SElinux could be at play here. Also, and I'm not sure how/if this applies to Perl, but if you are using object libraries, there must be a way for a linking loader to locate them, and the value of $LD_LIBRARY_PATH influences that. This could be different within the two environments. I don't think @INC would play a role in locating such libraries, only Perl modules, but you should be able to test this. Another issue may be the use of mod-perl on the server. I know only that there are some subtle differences between plain Perl and mod-perl, and it seems like one possible avenue to explore.
Interesting problem. Hope this helps.
--- rod.

There is no mod_perl as far as I see. Are the mysqld and the webserver running on the same box? Can't you install the DBD::mysql in a global way? Seems @INC contains different elements depending on the user excuting perl.