494107 - During NSS_NoDB_Init(), softoken tries but fails to load libsqlite3.so crash [@ @0x0 ]

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

A Sun developer reports that, when NSS 3.11.x is replaced by NSS 3.12.3 on
Linux, a program that was built to run with NSS 3.11.x fails to start up.
The call that reportedly fails is NSS_NoDB_Init(NULL). 
The error code is PR_LOAD_LIBRARY_ERROR.  
The error occurs when softoken attempts to load libsqlite3.so.  

In this particular case, NSS 3.12.3 was installed in /opt/sun/private/lib 
as a replacement for NSS 3.11.x which was previously there.  Output from 
ldd confirms that the application program is linked to expect all the NSS and NSPR shared libraries to be in that directory.  LD_LIBRARY_PATH is set to a 
path that includes only one directory, which is not /opt/sun/private/lib,
and also is not any standard system "lib" library.  

Softoken should be able to load any DB shared libs from the same directory where softoken itself is installed, but it fails to do so.  Output from the
strace program appears to show that attempts are made to look for the 
libsqlite3.so library in numerous directories, none of which is the directory
where softoken and libsqlite3.so are located.  

The application has not used a "sql" prefix for the directory name, and the 
environment does not contain an environment variable telling Softoken to use
sqlite, yet the softoken is trying to use sqlite.

I have not yet reproduced these results, however, the substantial amounts of
documentation (e.g. strace output) makes me not doubt that it is real.  

In my mind, reasonable questions to ask include: 
- why is Softoken trying to use libsqlite3 in this case?
- why does it not attempt to load libsqlite3 from the directory where 
softoken itself is located?

This bug is likely to necessitate an update to a version that is newer than
NSS 3.12.4 RC0 (in other words, newer than the present FIPS candidate), IMO.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Attachment: strace output

Attached Here is strace output from the failed run.

Here is ldd output from the application:

        libssl3.so      => /opt/sun/private/lib/libssl3.so (0x0068b000)
        libnss3.so      => /opt/sun/private/lib/libnss3.so (0x009ad000)
        libplc4.so      => /opt/sun/private/lib/libplc4.so (0x00380000)
        libplds4.so     => /opt/sun/private/lib/libplds4.so (0x0036d000)
        libnspr4.so     => /opt/sun/private/lib/libnspr4.so (0x006fd000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0048a000)
        libdl.so.2      => /lib/libdl.so.2 (0x00111000)
        libstdc++.so.6  => /usr/lib/libstdc++.so.6 (0x00236000)
        libm.so.6       => /lib/tls/libm.so.6 (0x00812000)
        libgcc_s.so.1   => /lib/libgcc_s.so.1 (0x00376000)
        libc.so.6       => /lib/tls/libc.so.6 (0x0049c000)
        libnssutil3.so  => /opt/sun/private/lib/libnssutil3.so (0x00d86000)
        /lib/ld-linux.so.2 (0x0066a000)

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Bob has asked for the following information for this bug.
1) On what distro and version of Linux is this occurring?
2) please attach ldd output for /opt/sun/private/lib/libnss3.so

Comment 3

[Robert Relyea]

> 2) please attach ldd output for /opt/sun/private/lib/libnss3.so

Actually that should be /opt/sun/private/lib/libsoftokn3.so

bob

Comment 4

[Julien Pierre]

FYI, I ran pp which invokes NSS_NoDB_Init. I set breakpoints in dlopen. I only hit them on libsoftokn3.so and libfreebl3.so, but not for libsqlite3.so, nor for libnssdbm3.so .  This was both on Solaris 10 x86 and Linux RHEL4 . I tried the RTM version of 3.12.3 from /share/builds/components which presumably Amy is using too. 

Amy, I would like to see a stack that shows where libsqlite3.so is being loaded from in your test case.

Comment 5

[Robert Relyea]

I suspect it's the loader that's making the call. Try removing libsqlite.so and run pp again. As I mentioned, softoken does not explicitly load sqlite, it only 'links' with it and expects the loader to resolve the symbol.

The question is why isn't it resolving if libsqlite.so lives in the same directory as softoken (are there some linker flags we are missing?). I also suspect it depends on the OS. On RHEL-5, I believe sqlite.so is part of the OS by default.

bob

Comment 6

[Julien Pierre]

I did an ldd on softoken. It turns out softoken is implicitly loaded with libsqlite3.so . It's not loading it with dlopen. So, libsqlite will always be in the process, even if applications are not using it.

[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib 30 % ldd libsoftokn3.so
        linux-gate.so.1 =>  (0xffffe000)
        libnssutil3.so => ./libnssutil3.so (0xf7f99000)
        libsqlite3.so => ./libsqlite3.so (0xf7f3b000)
        libplc4.so => ./libplc4.so (0xf7f36000)
        libplds4.so => ./libplds4.so (0xf7f32000)
        libnspr4.so => ./libnspr4.so (0xf7ef2000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xf7eaf000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7eab000)
        libc.so.6 => /lib/tls/libc.so.6 (0xf7d80000)
        /lib/ld-linux.so.2 (0x56555000)

Most likely, if LD_LIBRARY_PATH is not set, and the application is linked against libnss3.so only, NSS tries to load softoken first, but that fails because it can't find the dependency. I think normally we solve with problem by linking with $ORIGIN on Solaris, which lets a library find all its dependencies in the same directory.  $ORIGIN also exists on HP-UX. Is there any equivalent of $ORIGIN for Linux ?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Glen, please see if you can reproduce this on Linux with pp or certutil from 
NSS 3.12.3.

Comment 8

[Amy K.]

1. /opt/sun/mq/lib/        <--- libmqcrt.so
    libmqcrt.so built with
    -L<NSSLIBDIR> -lssl3 -lnss3 -lplc4 -lplds4 -lnspr4 -lpthread -ldl -Wl,-rpath=\$$ORIGIN/../../nss/lib -Wl,-rpath /opt/sun/private/lib

2. /opt/sun/private/lib   <--- contains all NSPR/NSS libraries

3. LD_LIBRARY_PATH=/top/sun/mq/lib
    A. ldd SessionClose    <-- the test program uses functions in libmqcrt.so 
        libmqcrt.so.1 => /opt/sun/mq/lib/libmqcrt.so.1 (0x004ba000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00abc000)
        libm.so.6 => /lib/tls/libm.so.6 (0x007b4000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a15000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00687000)
        libssl3.so => /opt/sun/private/lib/libssl3.so (0x00111000)
        libnss3.so => /opt/sun/private/lib/libnss3.so (0x0013e000)
        libplc4.so => /opt/sun/private/lib/libplc4.so (0x00c01000)
        libplds4.so => /opt/sun/private/lib/libplds4.so (0x00250000)
        libnspr4.so => /opt/sun/private/lib/libnspr4.so (0x00253000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x008e2000)
        libdl.so.2 => /lib/libdl.so.2 (0x007d9000)
        /lib/ld-linux.so.2 (0x0066a000)
        libnssutil3.so => /opt/sun/private/lib/libnssutil3.so (0x00e74000

      B. ldd /opt/sun/mq/lib/libmqcrt.so
        libssl3.so => /opt/sun/private/lib/libssl3.so (0x004ce000)
        libnss3.so => /opt/sun/private/lib/libnss3.so (0x001aa000)
        libplc4.so => /opt/sun/private/lib/libplc4.so (0x00c61000)
        libplds4.so => /opt/sun/private/lib/libplds4.so (0x002bc000)
        libnspr4.so => /opt/sun/private/lib/libnspr4.so (0x002bf000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00695000)
        libdl.so.2 => /lib/libdl.so.2 (0x002f2000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00947000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00c07000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00361000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00369000)
        libnssutil3.so => /opt/sun/private/lib/libnssutil3.so (0x002f6000)
        /lib/ld-linux.so.2 (0x0066a000)

      C. ldd /opt/sun/private/lib/libsoftokn3.so
           libnssutil3.so => not found
          libsqlite3.so => not found
          libplc4.so => not found
          libplds4.so => not found
         libnspr4.so => not found
         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c3c000)
         libdl.so.2 => /lib/libdl.so.2 (0x0021e000)
         libc.so.6 => /lib/tls/libc.so.6 (0x008d1000)
         /lib/ld-linux.so.2 (0x0066a000)

      D. run SessionClose
      Create connection ...
    "Preparing for NSS initialization ..."
    "Initializing NSS ..."
    "Could not connect to broker because 'PR_LOAD_LIBRARY_ERROR' (-5977)."
    setup: Error: PR_LOAD_LIBRARY_ERROR
    setup: ErrorTrace:
    callOnceNSS_Init(NULL):../../../../src/share/cclient/client/Connection.cpp:224:mq:-5977
    openConnection:../../../../src/share/cclient/client/Connection.cpp:294:mq:-5977
MQCreateConnectionExt:../../../../src/share/cclient/cshim/iMQConnectionShim.cpp:176:mq:-5977

Comment 9

[Robert Relyea]

The version of Linux would be extremely helpful here.

From the LDD it appears to be a relatively old version (older then RHEL 4.5 or RHEL 5.0, otherwise the ldd on libsoftoken3.so would have picked up the system versions of at list libplc4.so, plds4.so, and libnsrp4.so).

I did the same ldd on my system (Fedora 10) without setting an LD_LIBRARY_PATH and found they all the NSS shared libraries satisfied their dependencies from the system versions of the libraries, not the development ones in the same directory.

Supposition:
 From this I conclude that for most applications, NSS was picked up by including the NSS directory path in the LD_LIBRARY_PATH on most Linux applications.

It appears either tha CloseSession application, or libmqcrt was build with some sort of compile time library path, which allows the NSS libraries to resolve correctly. Since softoken is dynamically loaded, it does know know about this path, so it can't resolve it's dependent libraries.(This dynamic loading was required to prevent certain system apps from trying to modify addresses in softoken and freebl causing them to fail to start in FIPS mode).

If this supposition is correct I can see a couple of ways that could be used to get around this problem....

1) For this version of Linux, create an implicit requirement for sqlite3 in nss3 (that is reference an sqlite3 symbol in nss3 and add sqlite3 to it's link requirements). This can probably be accomplished with a simple makefile change.

2) For this version of linux revert pk11load.c to continue to implicitly require libsoftoken.so.

Ways the issue could be resolved at the application layer:

1) include sqlite3 as an implicit requirement for the application
2) place a link to sqlite3 in their LD_LIBRARY_PATH (package only change).
3) set LD_LIBRARY_PATH correctly (safest of all fixes).

None of these should be required on RHEL4 or RHEL5 systems since they already include a system version of sqlite as part of the default install.

bob

Comment 10

[Amy K.]

right,  libnspr4.so, libplc4.so and libplds4.so are on the system in /usr/lib/.
The previous ldd libsoftokn3.so was obtained by temporarily renamed these 3 NSPR
.so in /usr/lib to see if their existance interferring the issue.  They are not,
either way the PR_LOAD_LIBRARY_ERROR occurs.  Here is the ldd libsoftokn3.so
output with these system NSPR .so presents,
       >ldd libsoftokn3.so
        libnssutil3.so => not found
        libsqlite3.so => not found
        libplc4.so => /usr/lib/libplc4.so (0x00851000)
        libplds4.so => /usr/lib/libplds4.so (0x00540000)
        libnspr4.so => /usr/lib/libnspr4.so (0x004c4000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00a1d000)
        libdl.so.2 => /lib/libdl.so.2 (0x00593000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00111000)
        /lib/ld-linux.so.2 (0x0066a000)

%uname -a
Linux mqvx7 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux

%cat rehat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)

The above #1) and #2) workaround at applciation layer can't apply;
On #3), LD_LIBRARY_PATH is set correctly.  sqlite3 is a NSPR/NSS
private library, it should be handled at NSPR/NSS layer.

Comment 11

[Julien Pierre]

Nelson,

Re: comment 7, I already tried pp on Linux last week, and couldn't reproduce the problem. I tried to create a test case and couldn't. Now that Amy has posted her application link line, which includes the rpath, it should be much easier to do so.

Re: comment 9,
I don't think the app should link with sqlite, since it is private to softoken.
LD_LIBRARY_PATH shouldn't be required either.

I think the preferred solution would be that we fix the linking for libsoftokn3.so and get $ORIGIN to work, so that it will locate libsqlite3.so in the same directory . I am not sure on which versions of Linux that works, if any.

Comment 12

[Robert Relyea]

Julien, I refer to you my suggestions 1 and 2. Neither has anything to do with the application (and can be tested relatively quickly...

I'm not sure Linux supports $ORIGIN in the same way Solaris does. At this point I would be worried about breaking apps that are depending on pickup up system libraries...

Comment 13

[Julien Pierre]

I still can't create a test case that reproduces the problem. Here is what I did.

[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 287 % unsetenv LD_LIBRARY_PATH
[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 288 % cat test.c
#include <nspr.h>
#include <nss.h>
#include <stdio.h>

int main(int argc, char** argv)
{
        SECStatus rv = NSS_NoDB_Init(0);
        if (SECSuccess != rv) printf("Failure.\n"); else printf("Success !\n");
        return 0;
}
[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 289 % cat build
#!/bin/ksh
gcc -m32 -o test -I ../../public/nss -I ../../../nsprpub/pr/include test.c -I ../include/ -L /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib -l nss3 -Wl,-rpath /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib
[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 290 % ./build
[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 291 % ./test
Success !
[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 292 %

I also tried on Amy's RHEL4 machine, and the program runs there just as well. 

I am linking an executable (test), and Amy is linking a shared library (libmqcrt.so), so that could be the difference.

Comment 14

[Julien Pierre]

Bob,

Re: comment 12,
It looks like you had 5 different suggestions - some in NSS, and some in the application layer. But you re-used the numbers 1 and 2.

I would try your suggestions if I had reproduced Amy's problem, but so far, I have not.

Comment 15

[Julien Pierre]

FYI, here is an ldd of the test program I ran in comment 13 :

[jp96085@nssamdrhel4]/net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin 294 % ldd ./test
        linux-gate.so.1 =>  (0xffffe000)
        libnss3.so => /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib/libnss3.so (0xf7ea8000)
        libc.so.6 => /lib/tls/libc.so.6 (0x003f6000)
        libnssutil3.so => /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib/libnssutil3.so (0xf7e5b000)
        libplc4.so => /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib/libplc4.so (0xf7e56000)
        libplds4.so => /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib/libplds4.so (0xf7e52000)
        libnspr4.so => /net/monstre/export/home/julien/nss/tip/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib/libnspr4.so (0xf7e11000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00558000)
        libdl.so.2 => /lib/libdl.so.2 (0x00523000)
        /lib/ld-linux.so.2 (0x003dd000)

So it is really picking up my own libs. I even moved away the libsoftokn3.so from /usr/lib to make sure it wasn't being loaded, and the test program still ran. So I can only assume that it loaded the proper libsoftokn3.so that I built.
I would need a Linux equivalent of pldd to be 100% sure. I will seek one.

I guess there must be a difference due to the fact that Amy is building a shared lib and I am building an executable, since I used similar link options.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

In https://bugzilla.mozilla.org/show_bug.cgi?id=448792#c39 Wan-Teh suggests 
that $ORIGIN does work in at lease some flavor of Linux.

By the way, yesterday I received a report of essentially this very same bug
happening on Solaris 9 with a SetUID Root program.  Just as in this case,
the dlopen of libsoftokn3 fails because ld.so.1 does not find libsqlite3.so,
even though it's right in the same directory.

Comment 17

[Julien Pierre]

Nelson,

Re: comment 16,

I remember that there are some limitations of the runtime linker in setuid programs. I don't exactly remember which. ORIGIN processing may be one of them :-( But I couldn't find anything about that by googling.

Thanks for the link to that other bug. There was a comment that states that the rpath only applies to the specific shared library in that bug. I'm not sure that's true. At least, my rpath on the executable seemed to apply to all runtime loading in the process. Perhaps the rpath in the executable applies to all code loaded in the process, but the rpath in shared libs only applies to code in that shared lib. That would explain why I couldn't reproduce the problem with my executable, but Amy could.

Comment 18

[Julien Pierre]

From man ld.so.1 on Solaris :

     In a secure process, runpath components that are provided by
     the  application  or  any of its dependencies are used, pro-
     vided the component is a full path name, that is,  the  path
     name starts with a '/'.


     In a secure process, the expansion of the $ORIGIN string  is
     allowed  only  if the string expands to a trusted directory.
     However, should a $ORIGIN expansion match a  directory  that
     has  already  provided  dependencies,  then the directory is
     implicitly secure. This directory can  be  used  to  provide
     additional dependencies.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Amy, is the mq program a SetUID root program, by any chance?

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

Julien, 
My recollection is that, in a "secure process", a dlopen can only load a 
shared lib if at least one of the following is true:

1) The shared lib is in a trusted directory (A directory that has been 
explicitly designated as trusted with the crle program), or 

2) The path passed to dlopen is an absolute path (starts with /).  

I'm now wondering if the same thing is true for ordinary dependencies.

Comment 21

[Amy K.]

No,  the test program is not a setuid root program.

Comment 22

[glen beasley]

Attachment: set rpath for Solaris and Linux platforms that packages are provider for

I believe that that users who are experiencing this bug are using the sun packages, and relying on the rpath to be set correctly.

Comment 23

[Julien Pierre]

Comment on attachment 381176 [details] [diff] [review]
set rpath for Solaris and Linux platforms that packages are provider for

The change to platlibs.mk is wrong. I think the rpath still should be set to the old value if BUILD_SUN_PKG is not set. This is the reason for r-.

In lib/nss/config.mk, the comment you copied to the Linux section says
"The -R '$ORIGIN' linker option", but the option has a different name on Linux. Please write down the correct name.
Also, you should note that this $ORIGIN option doesn't work 100% on Linux as we found out last week. We may want to test on newer versions of RHEL to see if it does.

Same issue with the comment in softoken/config.mk .

Comment 24

[glen beasley]

Attachment: update rpath for Linux and solaris (checked in)

thanks Julien. 

I added the default $ORIGIN back to platlibs.mk for Linux. 

It turns out my test case last week was incorrect and 
rpath $ORIGIN does work %100 percent when it is compiled correctly into 
the library. 

Way to check the RPATH setting: 
Linux: 
objdump -p libsoftokn3.so | grep RPATH

Solaris:
dump -Lv libsoftokn3.so | grep RPATH

Comment 25

[glen beasley]

Thanks for the review Julien.

Checking in cmd/platlibs.mk;
/cvsroot/mozilla/security/nss/cmd/platlibs.mk,v  <--  platlibs.mk
new revision: 1.62; previous revision: 1.61
done
Checking in lib/nss/config.mk;
/cvsroot/mozilla/security/nss/lib/nss/config.mk,v  <--  config.mk
new revision: 1.34; previous revision: 1.33
done
Checking in lib/softoken/config.mk;
/cvsroot/mozilla/security/nss/lib/softoken/config.mk,v  <--  config.mk
new revision: 1.28; previous revision: 1.27
done

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

If I recall correctly, We decided today to change this fix, so that $ORIGIN 
will be used in RPATH in Sun's builds but not in RedHat's builds.  I wonder
about Mozilla's builds.

Comment 27

[Julien Pierre]

If Mozilla builds on Linux are bundling their own copy of NSS, then I think they want the $ORIGIN change in order to avoid picking up things from /usr/lib .
I think that is the case - the NSS copies in /usr/lib have no ECC, the copies from Mozilla have basic ECC, and the Sun copy has Extended ECC .

Comment 28

[Julien Pierre]

Also, re: the suggestion to do this in coreconf instead of individual config.mk files, I don't know if that's what we want to do. There was a time when we had some shared libraries under cmd for libpkix . This code has not been built for a while. But I can certainly see some things like cmd/lib going into a (private) shared lib eventually. I don't think we want the rpath for system locations hardcoded into that. So I would vote for not hardcoding the rpath into coreconf.

Comment 29

[Julien Pierre]

Attachment: Changes for RH build (checked in)

Don't set rpath of ORIGIN on RH Linux unless it's the Mozilla build, or Sun build.

Comment 30

[Robert Relyea]

Comment on attachment 382424 [details] [diff] [review]
Changes for RH build (checked in)

r+

Though I really prefer this to go to core conf. 

Right now you are not doing this for ssl3 smime3, nssutil3, etc. It seems to me you either want to always set it for NSS shared libraries or never set it.

bob

Comment 31

[Robert Relyea]

re comment 28 ...

I'm no sure what you mean by 'hard coded'. If it affects all the libraries in NSS, it should go into coreconf. 

shared libraries under cmd are part of cmd and are handled by platlib.mk files.

bob

Comment 32

[Julien Pierre]

Bob,

Yes, we probably should do it for the other libs.
My concern about hardcoding was that if we add this to the MKSHLIB make variable in coreconf, then we can no longer build shared libs in cmd that wouldn't have this rpath. We would need some extra intermediate variables that we could choose not to include for the tools build.

Comment 33

[Julien Pierre]

Attachment: Patch for coreconf (checked in)

Comment 34

[Robert Relyea]

Comment on attachment 382617 [details] [diff] [review]
Patch for coreconf (checked in)

r+ rrelyea

looks good.

bob

Comment 35

[Julien Pierre]

Thanks for the review, Bob.

Checking in security/coreconf/HP-UX.mk;
/cvsroot/mozilla/security/coreconf/HP-UX.mk,v  <--  HP-UX.mk
new revision: 1.12; previous revision: 1.11
done
Checking in security/coreconf/Linux.mk;
/cvsroot/mozilla/security/coreconf/Linux.mk,v  <--  Linux.mk
new revision: 1.38; previous revision: 1.37
done
Checking in security/coreconf/Linux2.1.mk;
/cvsroot/mozilla/security/coreconf/Linux2.1.mk,v  <--  Linux2.1.mk
new revision: 1.7; previous revision: 1.6
done
Checking in security/coreconf/Linux2.2.mk;
/cvsroot/mozilla/security/coreconf/Linux2.2.mk,v  <--  Linux2.2.mk
new revision: 1.7; previous revision: 1.6
done
Checking in security/coreconf/Linux2.4.mk;
/cvsroot/mozilla/security/coreconf/Linux2.4.mk,v  <--  Linux2.4.mk
new revision: 1.7; previous revision: 1.6
done
Checking in security/coreconf/Linux2.5.mk;
/cvsroot/mozilla/security/coreconf/Linux2.5.mk,v  <--  Linux2.5.mk
new revision: 1.6; previous revision: 1.5
done
Checking in security/coreconf/Linux2.6.mk;
/cvsroot/mozilla/security/coreconf/Linux2.6.mk,v  <--  Linux2.6.mk
new revision: 1.6; previous revision: 1.5
done
Checking in security/coreconf/SunOS5.mk;
/cvsroot/mozilla/security/coreconf/SunOS5.mk,v  <--  SunOS5.mk
new revision: 1.26; previous revision: 1.25
done
Checking in security/nss/lib/ckfw/builtins/config.mk;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/config.mk,v  <--  config.mk
new revision: 1.14; previous revision: 1.13
done
Checking in security/nss/lib/ckfw/capi/config.mk;
/cvsroot/mozilla/security/nss/lib/ckfw/capi/config.mk,v  <--  config.mk
new revision: 1.3; previous revision: 1.2
done
Checking in security/nss/lib/freebl/Makefile;
/cvsroot/mozilla/security/nss/lib/freebl/Makefile,v  <--  Makefile
new revision: 1.108; previous revision: 1.107
done
Checking in security/nss/lib/nss/config.mk;
/cvsroot/mozilla/security/nss/lib/nss/config.mk,v  <--  config.mk
new revision: 1.35; previous revision: 1.34
done
Checking in security/nss/lib/smime/config.mk;
/cvsroot/mozilla/security/nss/lib/smime/config.mk,v  <--  config.mk
new revision: 1.28; previous revision: 1.27
done
Checking in security/nss/lib/softoken/config.mk;
/cvsroot/mozilla/security/nss/lib/softoken/config.mk,v  <--  config.mk
new revision: 1.29; previous revision: 1.28
done
Checking in security/nss/lib/softoken/legacydb/config.mk;
/cvsroot/mozilla/security/nss/lib/softoken/legacydb/config.mk,v  <--  config.mk
new revision: 1.11; previous revision: 1.10
done
Checking in security/nss/lib/sqlite/config.mk;
/cvsroot/mozilla/security/nss/lib/sqlite/config.mk,v  <--  config.mk
new revision: 1.6; previous revision: 1.5
done
Checking in security/nss/lib/ssl/config.mk;
/cvsroot/mozilla/security/nss/lib/ssl/config.mk,v  <--  config.mk
new revision: 1.29; previous revision: 1.28
done
Checking in security/nss/lib/util/config.mk;
/cvsroot/mozilla/security/nss/lib/util/config.mk,v  <--  config.mk
new revision: 1.5; previous revision: 1.4
done

Comment 36

[Wan-Teh Chang]

There are two problems with the use of MOZILLA_CLIENT in
the patch for coreconf (attachment 382617 [details] [diff] [review]).

1. If I want to build NSS with -Wl,-rpath,'$$ORIGIN' on
Linux, I am now forced to set MOZILLA_CLIENT, which will
also change the NSS build in several other ways that I'm
not interested in.

-Wl,-rpath,'$$ORIGIN' is useful, so I think it should
not be tied to the MOZILLA_CLIENT variable.

2. The patch seems to use !BUILD_SUN_PKG && !MOZILLA_CLIENT
to mean "build Red Hat/Fedora package", which would be true
if Sun, Red Hat, and Mozilla were the only parties building
NSS.

I seem to remember that Fedora disallows system libraries
to be linked with -rpath (or perhaps -rpath $ORIGIN
specifically).  If this is why Red Hat/Fedora needs to
turn off -Wl,-rpath,'$$ORIGIN', I think it should be handled
by patching NSS in the NSS RPM spec file.  Alternatively, we
can add a BUILD_FEDORA_PKG variable.

Comment 37

[Julien Pierre]

Wan-Teh,

We had a discussion about this in the meeting a week ago.
Bob said he didn't want to have -Wl,-rpath,'$$ORIGIN' in Red Hat builds because he said it could break some RH customers. It wasn't because this option is disallowed on Fedora/RH.

2. Yes, that's what the patch does. I looked for a RH-specific build variable but didn't find one. Perhaps one should be added.

Comment 38

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh, thanks for your comments.  We all want to do the right thing here
that is best for all concerned.  If you have any alternatives to suggest,
please do.  We need to act quickly though.  FIPS is slipping.

Comment 39

[Wan-Teh Chang]

Attachment: Remove MOZILLA_CLIENT from Linux.mk

Mozilla doesn't need -Wl,-rpath,'$$ORIGIN' because it invokes
the Firefox or Thunderbird executable through a shell script
that sets LD_LIBRARY_PATH properly:
http://mxr.mozilla.org/mozilla-central/source/build/unix/run-mozilla.sh

I also found that on Linux, I can run 'certutil' without linking
any of the NSS shared libraries with -Wl,-rpath,'$$ORIGIN'.  I
don't understand how libsoftokn3.so can load libsqlite3.so...
(I know it's not using the system libsqlite3.so.)

Comment 40

[Wan-Teh Chang]

Attachment: Remove MOZILLA_CLIENT from Linux.mk, v2 (checked in)

The previous patch includes an unrelated change by accident.

Comment 41

[Wan-Teh Chang]

Attachment: Fix a minor bug in cmd/platlibs.mk (checked in)

I found a minor problem in the patch "update rpath for Linux and solaris"
(attachment 381436 [details] [diff] [review]).  We should add an "else" after BUILD_SUN_PKG, so
that we don't add redundant -rpath flags in the BUILD_SUN_PKG case.

Comment 42

[Nelson Bolyard (seldom reads bugmail)]

reopening.  Patches attached to resolved bugs are typically ignored.

Comment 43

[Wan-Teh Chang]

Comment on attachment 383292 [details] [diff] [review]
Fix a minor bug in cmd/platlibs.mk (checked in)

Checking in platlibs.mk;
/cvsroot/mozilla/security/nss/cmd/platlibs.mk,v  <--  platlibs.mk
new revision: 1.63; previous revision: 1.62
done

Comment 44

[Julien Pierre]

Comment on attachment 383290 [details] [diff] [review]
Remove MOZILLA_CLIENT from Linux.mk, v2 (checked in)

Wan-Teh,

Presumably the $ORIGIN wasn't necessary for Mozilla before, so removing it is OK. I thought you wanted to have it for the google build of NSS, though.
On Solaris we have builds of Mozilla that don't use the shell script and don't use LD_LIBRARY_PATH_. Perhaps there are no such builds on Linux.

Comment 45

[Wan-Teh Chang]

Comment on attachment 383290 [details] [diff] [review]
Remove MOZILLA_CLIENT from Linux.mk, v2 (checked in)

There's no Google build of NSS.  (I build NSS for personal use.)
I just wanted to contain the use of MOZILLA_CLIENT in old code.
In new code we should use product-neutral build variables such as
OPT_CODE_SIZE.

Checking in Linux.mk;
/cvsroot/mozilla/security/coreconf/Linux.mk,v  <--  Linux.mk
new revision: 1.39; previous revision: 1.38
done

Comment 47

[Julien Pierre]

Attachment: Consolidates previous 5 patches, for 3.12.3.2

Comment 48

[Julien Pierre]

Comment on attachment 393886 [details] [diff] [review]
Consolidates previous 5 patches, for 3.12.3.2

This patch should have been in bug 508108 .

Comment 49

[Julien Pierre]

Wan-Teh pointed out at https://bugzilla.mozilla.org/show_bug.cgi?id=508108#c24 that the change I made in HP-UX.mk in attachment 382617 [details] [diff] [review] is not correct for ia64 as it can be built 32 bits as well. This is something I was unaware of, and probably Bob as well in his review. I am reopening this bug so that the correct behavior can be restored. I wonder who is actually building on ia64/32, though.

Comment 50

[Julien Pierre]

Attachment: Fix ia64 32 bits build

Comment 51

[Wan-Teh Chang]

Comment on attachment 394186 [details] [diff] [review]
Fix ia64 32 bits build

r=wtc.

> 
> DSO_LDOPTS		= -b +h $(notdir $@)
>-ifeq ($(USE_64), 1)
> RPATH   = +b '$$ORIGIN'
>+ifneq ($(OS_TEST),ia64)
>+# pa-risc
>+ifndef USE_64
>+RPATH   =
>+endif
> endif
> DSO_LDFLAGS		=

Nit: you may want to use TABs between RPATH and = so that
the = signs are aligned with the nearby = signs in this file.

Comment 52

[Julien Pierre]

Thanks, Wan-Teh.

Checking in HP-UX.mk;
/cvsroot/mozilla/security/coreconf/HP-UX.mk,v  <--  HP-UX.mk
new revision: 1.13; previous revision: 1.12
done

Comment 53

[Mike Beltzner [:beltzner, not reading bugmail]]

Need to make sure we get this fix in the version of NSS used on mozilla-1.9.2

Comment 54

[Daniel Veditz [:dveditz]]

Looks like wtc did that Aug 20 -- the 1.9.2 branch is now using NSS 3.12.4.5
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?changeset=19c68e0defd5