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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4