Wan-Teh Chang wrote:
>Jamil Nimeh wrote:
>
>>I seem to recall a long time ago that things like certutil, keyutil,
>>modutil, etc. were statically linked binaries. Does anyone know if
>>there's a way to build these utilities from NSS 3.3 or 3.2 statically
>>linked with all the NSPR and NSS libs?
>>
>
>Linking the NSS utilities with NSPR and NSS static libs will require
>nontrivial modifications to the sources and makefiles on Solaris
>SPARC. This is because both NSPR and NSS use dynamic library
>loading techniques to load a faster implementation of some functions
>when running on UltraSPARC architectures.
>
>I'd like to know why you would like to statically link the utilities.
>I guess you consider it an inconvenience to have to set
>LD_LIBRARY_PATH. If so, there are two possible solutions:
>1. You can link these utilities with the Solaris linker flag
> -R $ORIGIN/../lib, assuming you install the utilities in
> <some-prefix>/bin and the NSPR and NSS shared libraries
> in <some-prefix>/lib. This technique only works on platforms
> whose linkers support the $ORIGIN keyword (or its equivalent).
>
One has to be careful of this method, because there are some libraries
that are loaded programatically. The program assumes that the dlopen()
call will open the same library as the adding the library to the linker
line, but the -R flag seems to defeat that.
>
>2. You can add a shell script wrapper for each of the NSS utilities.
> The shell script would set the LD_LIBRARY_PATH and invoke
> the binary executable. This solution is commonly used on Unix
> platforms for applications that are linked with shared libraries.
>
>Let us know if you'd like to see solution #2 implemented in a
>future NSS release. (Solution #1 only works on some platforms
>so we will not implement it.)
>
>Wan-Teh
>
