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

[Martin v. Loewis]

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

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

This was on Solaris, so no RPMs.

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

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

> 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

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

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

Indeed, it wouldn't.

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

Yes, that was the problem. Even with soft mounting, it will still take
time to timeout.

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

That is a reasonable argument, and I've been giving similar arguments
in other cases, too, so I guess I should just stop 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.

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

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

Regards,
Martin