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