Date: Tue, 11 Dec 2001 14:51:29 -0800 From: Joe Kelsey <joe@zircon.seattle.wa.us> To: freebsd-stable@freebsd.org Subject: rtld-elf issues Message-ID: <15382.36337.945315.693398@zircon.zircon.seattle.wa.us>
next in thread | raw e-mail | index | archive | help
What should rtld-elf do when asked to load an already loaded shared object? Currently, if you manually request loading of a shared object via dlopen, rtld-elf will recursively try to load any libraries that the shared object references. If the shared library references an already manually-loaded shared object, it still attempts to find the shared object via the various paths in effect at the time of the dlopen call. This is an unnecessary effort, since the module is already loaded, yet the search can fail and abort the program due to phantom dlopen errors. The reason that this is important is because of legacy linker commands in programs ported from Solaris and Linux, in particular the Java Mozilla plugin. For various obscure reasons, shared objects created by the default linker commands for the Java plugin reference a specific libjvm.so, even though the actual libjvm.so (green or native threads) is determined at run time and manually loaded. When the rtld-elf functions attempt to load one of these shared objects (libjavaplugin_jni.so for instance), it encounters the reference to libjvm.so and attempts to find it in the default LD_LIBRARY_PATH in effect at the time. However, libjvm.so is *not* in the LD_LIBRARY_PATH, since Java applications have to manually specify their threading model at run time, and the green vs. native selection is done prior to loading this particular shared object. Shouldn't the loader notice that libjvm.so is already mapped into the address space and skip checking for it on the disk? Presumably, although I haven't verified this in the rtld code, it would eventually find out the the library is already loaded further down the road when it actually attempts to map and already mapped file. If this is not the appropriate forum to raise this question, please let me know where to raise it. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15382.36337.945315.693398>