problem importing MySQLdb from a CGI

[John Speno]

This test program sometimes works when invoked via the web server via
CGI, but often doesn't:

    #!/usr/local/bin/python
    import cgi
    try:
        import MySQLdb
        cgi.test()
    except:
        print "Content-type: text/html\n"
        cgi.print_exception()

When it doesn't work, here's the exception:

    Traceback (most recent call last):

    File "./bad.cgi", line 7, in main
        import MySQLdb
      File "./MySQLdb/__init__.py", line 27, in ?
        import _mysql
    ImportError: ld.so.1: /usr/local/bin/python: fatal: libgcc_s.so.1:
    open failed: No such file or directory

It always works when run from the command line. The library file it can't
find does exist on a local (non NFS) filesystem. Setting LD_LIBRARY_PATH
in wrapper shell script didn't help either. When I built MySQLdb, I used
these params in setup.py:

    include_dirs = ['/usr/local/mysql/include']
    library_dirs = ['/usr/local/mysql/lib']
    libraries = [mysqlclient, "z", "gcc_s"]
    runtime_library_dirs = ['/usr/local/lib', '/usr/local/mysql/lib']
    extra_objects = []

I'm not sure if it matters, but the MySQLdb module is installed in the same
directory as the CGI script as I had to install it myself.

The web server is zeus 3.4, on an ISP's machine. I don't expect them to be
of much help, but I'm at a loss as to where to start looking for the
problem.  Any ideas would be appreciated.

Thanks!

[Skip Montanaro]

Looks like you're using GCC 3.0.  Make sure the directory containing libgcc_s.so is in /etc/ld.so.conf and that you've run ldconfig as root.  If that's not possible you'll have to convince your web server to set the LD_LIBRARY_PATH environment variable properly so that the gcc .so file can be loaded.

[John Speno]

Yes, GCC 3.03.

I don't think Solaris uses ld.so.conf, so I guess I'll have to go with the LD_LIBRARY_PATH. Where would they have to set it?

I already tried setting it in a shell script wrapper around my python program, like so:
    #!/bin/sh
    LD_LIBRARY_PATH=/usr/local/bin
    /usr/local/bin/python bad.cgi

And this has the same results.

Also, why would it work always from the command line, and even sometimes from CGI?

Thanks!

[Skip Montanaro]

You need to explicitly export LD_LIBRARY_PATH to subprocesses:

#!/bin/sh
LD_LIBRARY_PATH=/usr/local/bin
export LD_LIBRARY_PATH
/usr/local/bin/python bad.cgi

otherwise the change is only good for the current process.

Skip

[John Speno]

The shell wrapper, actually is:

    #!/bin/sh
    LD_LIBRARY_PATH=/usr/local/lib
    export LD_LIBRARY_PATH

    /usr/local/bin/python bad.cgi

Duh.

[Skip Montanaro]

Here's a different tack to take...  Try deleting LD_LIBRARY_PATH from your interactive environment to make your script fail there, then rebuild it directory-by-directory until you have it working interactively once again.  Use that value for LD_LIBRARY_PATH in your wrapper script.

If deleting LD_LIBRARY_PATH from your interactive environment doesn't break the script, something else is missing from your wrapper script...

Skip

[John Speno]

Thanks Skip.

The thing is that LD_LIBRARY_PATH isn't set in my interactive environment at all.

And setting it in the wrapper script doesn't even make the script work reliably. It stills works sometimes and not others.

ldd shows that _mysql.so knows where to find libgcc_s.so, so I don't know what else to do:

bash-2.03$ ldd _mysql.so
        libz.so =>       /usr/local/lib/libz.so
        libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1

[John Speno]

I just got word from the ISP hosting this CGI. It turns out that their web server is actually two web servers serving via a load balancer.

One of the hosts (the one I've been logging into all these times) is fine. However, the other one lacks a /usr/local/lib/libgcc_s.so.1.

D'oh!

I've asked them to fix the issue for me. I can only hope they will.

I need to learn to think outside of the box and into the other box sitting above it in the rack.