Closed Bug 323379 Opened 19 years ago Closed 19 years ago

[BeOS] Firefox build broken when signing security modules

Categories

(NSS :: Build, defect, P1)

3.11
x86
BeOS

Tracking

(Not tracked)

RESOLVED FIXED
3.11.1

People

(Reporter: doug, Assigned: wtc)

Details

Attachments

(1 file)

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
Summary: [BeOS} Firefox build broken when signing security modules → [BeOS] Firefox build broken when signing security modules
changing from Security to build config.  Seems to be related to checkin of NSS 3.11, bug 317620
Component: Security → Build Config
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.
Assignee: nobody → wtchang
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
Attachment #208654 - Flags: review?(christophe.ravel.bugs)
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.
Component: Build Config → Build
Flags: review?(christophe.ravel.bugs)
Product: Firefox → NSS
QA Contact: firefox → wtchang
Target Milestone: --- → 3.11.1
Version: unspecified → 3.11
Attachment #208654 - Flags: review?(christophe.ravel.bugs)
Thunderbird also builds cleanly with the patch.
Attachment #208654 - Flags: review?(christophe.ravel.bugs) → review+
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Priority: -- → P1
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: