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

As I read other postings with LD_LIBRARY_PATH in their titles, I see people talking about the need to “re-exec” things in order to make it actually work properly. Something about DynaLoader cacheing things...

Also, this seems vaguely like a Band-Aid® ... because I obviously do not yet understand the underlying mechanism (presumably DynaLoader) that Perl is using here. (I do understand the Linux dynamic-loader.) It seems vaguely odd to me that use base does not take care of “this, too.” Having to track-down a bunch of library-path locations does not feel right... as in “it might well work, but TMTOWTDI, and therefore is this really TBWTDI?”

Nevertheless... where's the right perldoc?

Hmmm... perldoc DynaLoader ... I'm looking hard at the discussion of the @dl_library_path variable.

The business of referring to the @INC variable looks very appealing, but... would it actually be reliable in the CGI-environment? I mean, “sure, it works in the command-line, but then again, so does my program.” As you can see, I am already specifying (I think...) the @INC entries by means of the use lib statement in the prologue of my code. (MENTAL FLASH!) Should I have put that statement in a BEGIN{} block?)

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 14:06 UTC

    Well, apparently not ... my “mental flash” apparently did not help.

    • I do know, from actual debug-logs in my code, that the @INC array does contain a path to a directory which contains auto/DBD/mysql/mysql.so, in both the command-line and the CGI environments.
    • Running the CGI program, on the target server, from the command-line, works correctly.
    • So, there is something wrong or not-specified in the CGI environment. That is the cause, and apparently the extent, of the problem.
    • Looking at the ldd output, as suggested, I see that libmysqlclient.so.15 is located in the trusted-library, /usr/lib. So there should be no problems there...

    Looking at perldoc DynaLoader, I observe (in the discussion of the bootstrap subroutine, which is described as “the normal entry point for automatic dynamic loading in Perl”), that it “locates an auto/$module directory by searching @INC” ... So I know that I am missing something that will soon cause me to slap my forehead vigorously.

    But right now, I have “hit a mine” and I am dead-in-the-water with the clock ticking fast.

      Maybe it's easier to debug this by just taking a look at what is actually going on under the hood — e.g. using strace.  Just create a wrapper something like this 

      #!/bin/sh
strace -o /tmp/strace.out -efile /path/to/your-cgi-script.pl

      [download]

      (The -efile is optional, and filters the output to only log file-related system calls, such as open, stat, access,...  In case your script involves subprocesses, you might want to use option -f, in order to trace forked processes, too.)

      Then compare non-working vs. working, i.e. the output you get when running it via the webserver against the output you get when you call it on the command line.

      This should give you a rather precise idea of which paths are being searched, what files are being opened, or aren't found, etc.  Maybe it's worth mentioning upfront that it's perfectly normal to get lots of "ENOENT (No such file or directory)" — this just shows what's being tried, not necessarily that there's a problem. It only indicates a problem if some file which needs to be loaded, is producing nothing but ENOENTs, or some other error. You get the idea...  In case you're having difficulties interpreting the details, just post the output here.

[reply]
[d/l]
[select]

        I didn't listen. Either time.

        “To those who come after,” carefully re-read the post that this is in-reply to.

In Section Seekers of Perl Wisdom