This bug only affects HP-UX. On HP-UX, PR_LoadLibrary calls shl_load() with the DYNAMIC_PATH flag. If an application is linked with the +s linker option, the DYNAMIC_PATH flag of shl_load() causes it to search for the shared library in some search path, such as that specified by the SHLIB_PATH environment variable. However, the way shl_load(DYNAMIC_PATH) uses the search path is very aggressive. For example, if you have a libfoo.sl on your SHLIB_PATH, all of the shl_load() calls below will succeed (assuming none of the specified pathnames refer to an existing file): shl_load("libfoo.sl", DYNAMIC_PATH|BIND_DEFERRED, 0); shl_load("./libfoo.sl", DYNAMIC_PATH|BIND_DEFERRED, 0); shl_load("../../lib/libfoo.sl", DYNAMIC_PATH|BIND_DEFERRED, 0); shl_load("/no/such/dir/libfoo.sl", DYNAMIC_PATH|BIND_DEFERRED, 0); shl_load("no/such/dir/libfoo.sl", DYNAMIC_PATH|BIND_DEFERRED, 0); One would expect that only the first call should succeed, i.e., the dynamic library search path should be used only when a plain file name, containing no directory, is specified. Indeed, this is the behavior of dlopen(). We should modify PR_LoadLibrary() to pass DYNAMIC_PATH to shl_load() only if the specified name is a plain file name, containing no directory, so that PR_LoadLibrary has the same behavior across all platforms.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → 4.1.1
I checked in the fix on the tip and NSPRPUB_RELEASE_4_1_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 65787 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.