in reply to Do XS-components require special considerations with CGI? [SOLVED]

This is a shared-hosting environment that does not permit access to the error-logs.

As I said, the program runs absolutely cleanly in the command-line environment of the shared host. I can invoke the program and a few milliseconds later I am rewarded with the correct HTML output.

As I also said, I have verified that the @INC array does include an entry from where the auto/DBD/mysql/mysql.so file can be reached. (I verified this by adding a debug-output to the web-site code so that the output is known to come from the server's environment.)

My reading of man DynaLoader seems to say that the @INC array contents are consulted to find the auto... entry; that fiddling of DL_LIBRARY_PATH ought not to be required...

My next attempt will be to see if I can replicate the problem from my own Apache server.

Replies are listed 'Best First'.
Re^2: Do XS-components require special considerations with CGI?
by locked_user sundialsvc4 (Abbot) on Feb 26, 2009 at 17:41 UTC

    My next attempt will be to see if I can replicate the problem from my own Apache server.

    Whimper! It works there, too!

    I can't see the problem, and I can't replicate it. All that this does seem to suggest is that the problem is not related to environment-variables... that is to say, that the use lib stuff does the right thing in both cases. (I do not install the Perl packages that are used for web-development “globally” on my system. I also rely upon .htaccess files just as shared-hosts do. The setup is designed to replicate shared-hosting, and I fully believe that it does so.)

    This basically means that, on my box, the mysql.so module is being located and run correctly from the Apache environment.

    <panic> OMG, I am so.... scroo'd ... </panic>

      So you've installed CPAN modules with binary parts locally? And it runs from the command line but not in the browser? Did you try something like this:

      chmod -R 755 ~/lib

      (where I'm assuming all your local modules are under ~/lib)

      Have you tried calling the host's customer support? Are you the first customer they've ever had to try using mysql?

      If so - maybe their installation is broke, and if you report it they will fix it. Else, if other customers have done it, maybe they can tell you what they did different (assuming they've done something non-standard they requires extra steps)

      Final option - switch hosts!

        chmod had no useful effect.

        Yes...

        1. If I “run” the script from the command line on that host, in a few milliseconds I get the correct, database-based, HTML output.
        2. If I attempt to access the page from the site, I get the application's error-screen, and the message previously mentioned is in the application's log.
        3. If I do the selfsame thing on my development system, it works.

        “Switching hosts” is not a practical alternative. What I did notice, when I googled "Undefined subroutine &DBD::mysql::db::_login", is that the problem isn't new. In fact, there are several sites out there which are exhibiting the very same problem right now.

        There were people yanking their hair out over this one in 2001, and even then not finding answers. Disturbing...