User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20060110 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20060110 Firefox/1.6a1 Unable to complete build of Firefox. Worked on 2006-01-10, fails now. Build breaks here: sh ./sign.sh /boot/home/develop/mozilla/opt-DEBUG/dist /boot/home/develop/mozilla/opt-DEBUG/nss BeOS /boot/home/develop/mozilla/opt-DEBUG/dist/lib /boot/home/develop/mozilla/opt-DEBUG/dist/lib/libsoftokn3.so /boot/home/develop/mozilla/opt-DEBUG/nss/shlibsign -v -i /boot/home/develop/mozilla/opt-DEBUG/dist/lib/libsoftokn3.so NSS_Init failed: An I/O error occurred during security authorization. make[5]: *** [/boot/home/develop/mozilla/opt-DEBUG/dist/lib/libsoftokn3.chk] Error 1 make[5]: Leaving directory `/boot/home/develop/mozilla/security/nss/cmd/shlibsign' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/boot/home/develop/mozilla/opt-DEBUG/security/manager' make[3]: *** [libs_tier_50] Error 2 make[3]: Leaving directory `/boot/home/develop/mozilla/opt-DEBUG' make[2]: *** [tier_50] Error 2 make[2]: Leaving directory `/boot/home/develop/mozilla/opt-DEBUG' make[1]: *** [default] Error 2 make[1]: Leaving directory `/boot/home/develop/mozilla/opt-DEBUG' make: *** [build] Error 2 $ Reproducible: Always Steps to Reproduce: 1.try to build (make -f client.mk build) 2.build fails as above 3. Actual Results: no complete build Expected Results: build completes successfully

changing from Security to build config. Seems to be related to checkin of NSS 3.11, bug 317620

The NSS_CLIENT_TAG was moved on 2006-01-13 at 10:25 -0800 (US Pacific Standard Time). I will describe a new change in NSS 3.11. Hopefully that will help you diagnose the problem. NSS 3.11 has a new file libfreebl3.so. libsoftokn3.so and libssl3.so load libfreebl3.so at run time using PR_LoadLibraryWithFlags. Most likely, libsoftokn3.so's loading of libfreebl3.so failed. Below I will use libsoftokn3.so as the example, but the same also applies to libssl3.so. libsoftokn3.so loads libfreebl3.so in three attempts. 1. It first looks for libfreebl3.so in the directory where libsoftokn3.so resides. That directory is determined using PR_GetLibraryFilePathname. Since PR_GetLibraryFilePathname is not implemented on BeOS, this attempt is expected to fail. It would be nice to figure out how to implement this function, although it's not required to fix this bug. 2. If the platform has symbolic links and the libsoftokn3.so is a symbolic link, resolve the symbolic link and try again. Again, since PR_GetLibraryFilePathname is not implemented on BeOS, this step won't be attempted on BeOS (whether BeOS has symbolic links or not). 3. Finally, load libfreebl3.so with just the file name "libfreebl3.so", relying on the shared library search path. NSS sets the shared library search path for shlibsign here: http://lxr.mozilla.org/seamonkey/source/security/nss/cmd/shlibsign/sign.sh#42 I believe the LIBRARY_PATH environment variable we set is for BeOS. Do you know why it's not working? Should we set ADDON_PATH, too? Does BeOS have two kinds of shared libraries, one kind you link with at build time, and the other kind (addon?) you load at run time? Note that the new shared library libfreebl3.so is loaded at run time, the same as libnssckbi.so.

(In reply to comment #2) > 3. Finally, load libfreebl3.so with just the > file name "libfreebl3.so", relying on the > shared library search path. NSS sets the > shared library search path for shlibsign > here: > http://lxr.mozilla.org/seamonkey/source/security/nss/cmd/shlibsign/sign.sh#42 > I believe the LIBRARY_PATH environment variable > we set is for BeOS. Do you know why it's not > working? Should we set ADDON_PATH, too? > > Does BeOS have two kinds of shared libraries, > one kind you link with at build time, and the > other kind (addon?) you load at run time? Note > that the new shared library libfreebl3.so is > loaded at run time, the same as libnssckbi.so. > I believe you have pinpointed the problem, but I'm not sure how to solve it. I know BeOS has some OS-specific work-arounds concerning shared libs. Unfortunately, I'm not knowledgeable enough to answer these questions myself, and our principle dev is off on holiday, but have asked for help in a BeOS-specific developers forum. I'm also looking at our handling of libnssckbi.so to see if I can understand what we need to do.

Doug: this is a wild guess. Please try this patch. It sets the ADDON_PATH environment variable in the sign.sh script we use to run the shlibsign tool. If this solves the problem, it would be nice to see if we can remove the two preceding lines that set LIBRARY_PATH from sign.sh.

The patch works, proving once again that an intelligent wild guess is worth far more than careful reason performed in ignorance. I'll try again without LIBRARY_PATH and post results momentarily.

LIBRARY_PATH is also required. sign.sh fails without it. Thank you for finding this. Patch definitely works here and is OK to commit. Can you commit as is, or is review/SR required?

Comment on attachment 208654 [details] [diff] [review] Set ADDON_PATH in sign.sh Christophe, could you review this patch for the NSS trunk and the NSS_3_11_BRANCH? We need to set the environment variable ADDON_PATH for BeOS. On other platforms, this environment variable is not used and will be ignored. Doug, thanks a lot for testing this patch. Can you finish the entire Mozilla build successfully with this patch applied?

Yes, Firefox build completes successfully. I'm in the process of updating so I can insure there are no complications in Thunderbird. I don't typically build SeaMonkey but I will if you see value in verifying a clean build there, too.

Doug: it's not necessary to build SeaMonkey. The reason I wanted to know if Firefox build completed successfully is to change the product of this bug to NSS.

Thunderbird also builds cleanly with the patch.

Fix checked in on the NSS trunk (3.12) and NSS_3_11_BRANCH (3.11.1). Checking in sign.sh; /cvsroot/mozilla/security/nss/cmd/shlibsign/sign.sh,v <-- sign.sh new revision: 1.17; previous revision: 1.16 done Checking in sign.sh; /cvsroot/mozilla/security/nss/cmd/shlibsign/sign.sh,v <-- sign.sh new revision: 1.16.2.1; previous revision: 1.16 done Moved NSS_CLIENT_TAG (Mozilla 1.9 alpha) on sign.sh. Thanks a lot for verifying the fix, Doug.