[Python-Dev] Please give this patch for building bsddb a try

[Barry A. Warsaw]

>>>>> "MvL" == Martin v Loewis <martin@v.loewis.de> writes:

    MvL> barry@zope.com (Barry A. Warsaw) writes:

    >> Really?  You know the path for the -R/--rpath flag, so all you
    >> need is the magic compiler-specific incantation, and distutils
    >> already (or /should/ already) know that.

    MvL> Yes, but you don't know whether usage of -R is appropriate.
    MvL> If the installed library is static, -R won't be needed.

And shouldn't hurt.
    
    MvL> If then the target directory recorded with -R happens to be
    MvL> on an unavailable NFS server at run-time (on a completely
    MvL> different network), you cannot import the library module
    MvL> anymore, which would otherwise work perfectly fine.

Do people still use NFS servers to share programs?  I thought big
cheap disks and RPMs did away with all that. :)

I believe that -R/-rpath adds directories to runtime search paths so
if the NFS directory was unmounted, ld.so should still be able to
locate the shared library through fallback means.  That may fail too,
but oh well.

One issue on Solaris may be that -- according to the GNU ld docs --
the runtime search path will be built from the -L options which we're
already passing, /unless/ -rpath is given, and this seems to be added
to help with NFS mounted directories on the -L specified path.  But
since I'm proposing that the -rpath directory be the same as the -L
path, I don't think it will make matters worse.

    MvL> We had big problems with recorded library directories over
    MvL> the years; at some point, the administrators decided to take
    MvL> the machine that had
    MvL> /usr/local/lib/gcc-lib/sparc-sun-solaris2.3/2.5.8 on it
    MvL> offline. They did not knew that they would thus make vim
    MvL> inoperable, which happened to be compiled with LD_RUN_PATH
    MvL> pointing to that directory - even though no library was ever
    MvL> needed from that directory.

Hmm.  Was the problem that the NFS server was unresponsive, or that
the directory was unmounted, but still searched?  If the former, then
maybe you do have a problem.  I've experienced hangs over the years
when NFS servers have been unresponsive (because the host was down and
the nfs mounts options weren't given to make this a soft error).  I
haven't used NFS in years though so my memory is rusty on the details.

    >> I disagree.  While the sysadmin should probably fiddle with
    >> /etc/ld.so.conf when he installs BerkeleyDB, it's not
    >> documented in the Sleepycat docs, so it's entirely possible
    >> that they haven't done it.

    MvL> I'm not asking for the administrator fiddle with
    MvL> ld.so.conf. Instead, I'm asking the administrator fiddle with
    MvL> Modules/Setup.

We've made it so easy to build a batteries-included Python that I
think it would be unfortunately not to do better just because we fear
that things /might/ go wrong in some strange environments.  I think
it's largely unnecessary to edit Modules/Setup these days, and since
we /know/ that BerkeleyDB is installed in a funky location not usually
on your ld.so path, I think we can take advantage of that to not
require editing Modules/Setup in this case too.

Our failure mode for bsddbmodule is so cryptic that it's very
difficult to figure out why it's not available.  I think this simple
change to setup.py[1] would improve the life for the average Python
programmer.  I'd be happy with a command line switch or envar to
disable the -R/--rpath addition.

Here's a compromise.  If LD_RUN_PATH is set at all (regardless of
value), don't add -R/--rpath.  Or add a --without-rpath switch to
configure.

    >> Note I'm not saying setting LD_RUN_PATH is the best approach,
    >> but it seemed like the most portable.  I couldn't figure out if
    >> distutils knew what the right compiler-specific switches are
    >> (i.e. "-R dir" on Solaris cc if memory serves, and "-Xlinker
    >> -rpath -Xlinker dir" for gcc, and who knows what for other Unix
    >> or <gasp> Windows compilers).

    MvL> LD_LIBRARY_PATH won't work for Windows compilers, either. To
    MvL> my knowledge, there is nothign equivalent on Windows.

Someone else will have to figure out the problems for Windows source
builders <wink>.  I'd like to make life just a little easier for Linux
and Unix users.  I think this change will do that.

-Barry

[1]

Index: setup.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.95
diff -u -r1.95 setup.py
--- setup.py	21 Jun 2002 14:48:38 -0000	1.95
+++ setup.py	24 Jun 2002 18:03:06 -0000
@@ -510,12 +510,14 @@
             if dbinc == 'db_185.h':
                 exts.append(Extension('bsddb', ['bsddbmodule.c'],
                                       library_dirs=[dblib_dir],
+                                      runtime_library_dirs=[dblib_dir],
                                       include_dirs=db_incs,
                                       define_macros=[('HAVE_DB_185_H',1)],
                                       libraries=[dblib]))
             else:
                 exts.append(Extension('bsddb', ['bsddbmodule.c'],
                                       library_dirs=[dblib_dir],
+                                      runtime_library_dirs=[dblib_dir],
                                       include_dirs=db_incs,
                                       libraries=[dblib]))
         else: