66286 - Problems finding libfreebl_*.so if the app is linked with libnss3.so with the -R option

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Wan-Teh Chang]

Some applications are linked with the shared libraries
it needs with the -R option so that at run time the user
does not need to set the LD_LIBRARY_PATH environment
variable.  The -R option is only used to search for the
direct dependencies of an app and is not used to search
for the dependencies of a direct dependency (such as
libnss3.so).  Therefore, apps linked with libnss3.so this
way have problems finding libnss3.so's dependencies
(libfreebl_*.so).

We do not have this problem on HP-UX (where libnss3.so
also needs libfreebl_*.so) because apparently the
equivalent +b linker option is used to search for both
direct and indirect dependencies.  This has been verified
by experiments.

Comment 1

[Wan-Teh Chang]

Attachment: Proposed patch.

Comment 2

[Wan-Teh Chang]

The proposed fix is to build libnss3.so with the -R '$ORIGIN'
linker option, which instructs libnss3.so to search for its
own dependencies (libfreebl_*.so) in the same directory where
it resides.  Unfortunately, we also need to make sure that
libnss3.so, not libnspr4.so, is the one that loads libfreebl_*.so,
so libnss3.so can't call PR_LoadLibraryWithFlags() to load
libfreebl_*.so and has to call dlopen() directly.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

As long as we're duplicating the implementation of 
PR_LoadLibraryWithFlags and PR_FindSymbol in loader.c 
for Solaris, we might as well also do so for HPUX,
and the other supported platforms as well.

Recall that other NSS libaries (DSOs) that are PKCS#11
modules do not link with NSPR, so they need implementations
of PR_LoadLibraryWithFlags and PR_FindSymbol for all 
platforms.  Presently they are using "stub" implementations.

Comment 4

[Wan-Teh Chang]

Attachment: Alternative patch. Duplicated the PR load library function code for both Solaris and HP-UX.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Review comment:

Can dlerror() ever return NULL?
How 'bout strerror()?

Otherwise looks good to me.

Comment 6

[Wan-Teh Chang]

Attachment: Revised alternate patch. Check for error != NULL before calling strlen(error) as Nelson suggested.

Comment 7

[Wan-Teh Chang]

I checked in the revised patch (id=23335) on the tip.