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

Barry A. Warsaw barry@zope.com
Mon, 24 Jun 2002 16:24:27 -0400


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

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

    MvL> This was on Solaris, so no RPMs.

I know, I was kind of joking.  But even Solaris has pkg, though I
don't know if it's in nearly as widespread use as Linux packages.

    >> 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.

    MvL> Yes, but the startup time for the program increases
    MvL> dramatically - it has to wait for the dead NFS server to
    MvL> timeout.

Yeah that would suck.  I wonder if that would only affect imports of
bsddb though since the Python executable itself wouldn't be linked
w/-R.

    >> 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

    MvL> Where do the docs say that? I don't think this is the case,
    MvL> or ever was ...

It's in the GNU ld info page under Options:

`-rpath DIR'
     [...]

     The `-rpath' option may also be used on SunOS.  By default, on
     SunOS, the linker will form a runtime search patch out of all the
     `-L' options it is given.  If a `-rpath' option is used, the
     runtime search path will be formed exclusively using the `-rpath'
     options, ignoring the `-L' options.  This can be useful when using
     gcc, which adds many `-L' options which may be on NFS mounted
     filesystems.

Reading it again now, it's not clear if "SunOS" also means "Solaris".

    >> 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.

    MvL> That is a reasonable argument, and I've been giving similar
    MvL> arguments in other cases, too, so I guess I should just stop
    MvL> complaining.

    >> 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.

    MvL> I guess we don't need to compromise, and approach is *very*
    MvL> cryptic, so I'd rather avoid it.

Cool.  I'll commit the change.

    MvL> It looks like the current bsddb module is going to go away,
    MvL> anyway, so there is no need to tweak the current
    MvL> configuration that much. I don't know what the bsddb3 build
    MvL> procedure is, but any approach you come up with now probably
    MvL> needs to be redone after pybsddb3 integration.

I suspect we'll need /something/ like this once pybsddb's integrated,
but I'll definitely be testing it once Greg does the integration.  I
doubt pybsddb's build process is going to just drop into place, and I
suspect it'll actually be easier.

Thanks,
-Barry