NSS3.4 / PSM Linux installer does not yet work.

VERIFIED DUPLICATE of bug 116334

Status

Core Graveyard
Security: UI
P1
normal
VERIFIED DUPLICATE of bug 116334
16 years ago
a year ago

People

(Reporter: kaie, Assigned: kaie)

Tracking

1.0 Branch
psm2.2
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

16 years ago
When trying to run the installer (build with
xpinstall/packager/unix/deliver.pl), messages are shown, and security doesn't
work in the installed application.

nsNativeComponentLoader:
SelfRegisterDll(/tmp/moztest/moz/components/libpipnss.so) Load FAILED with
error: libsmime3.so: cannot open shared object file: No such file or directory
(Assignee)

Comment 1

16 years ago
No NSS 3.4 landing without this, as it is required for shipping Mozilla
releases. Addding dependency.
Blocks: 116334
Status: NEW → ASSIGNED
(Assignee)

Updated

16 years ago
Blocks: 120633

Comment 2

16 years ago
When this is fixed we should make sure the installer works on win, linux, and mac.
(Assignee)

Comment 3

16 years ago
Created attachment 65990 [details] [diff] [review]
temporary fix

Status, to make sure we don't forget it:

This patch enables building a working shared library installer on Unix. I've
sent a package to junruh for testing.

No patch is required for the static unix build. However, the static installer
on unix does not work for me (seems to be not yet implemented, has nothing to
do with NSS).

Also included are installer patches for windows - although I have not yet ever
built an installer on windows. But the patches should be correct.

Note that although building Mozilla on Windows works fine, both in static and
shared mode, the PSM for NSS 3.4 makefiles currently use NSS DLLs in both
modes, and therefore until we fix it, the NSS DLLs must be packaged with the
installer in static mode, too.


This patch is not for checkin yet, because I don't see a simple way to make the
behaviour dynamically based on NSS 3.4, and I think we shouldn't try to make it
work. I suggest we delay checking this in until we activate NSS 3.4 as the
default.
(Assignee)

Comment 4

16 years ago
This no longer blocks 116334.
No longer blocks: 116334

Comment 5

16 years ago
I see that this bug blocks bug 120633, which in turn blocks 116334. This may be
sufficient.

We don't want to keep track of this. 116334 is not resolved until this one is
resolved. They may be checked in at the same time.

Priority: -- → P1
Target Milestone: --- → 2.2
Version: unspecified → 2.2
(Assignee)

Comment 6

16 years ago
Well, you're right. I'm re-adding the blocking dependency. In fact I wanted to
make this one *depend* on 116334 instead, but Bugzilla didn't allow that,
because that would introduce a circular dependency.
Blocks: 116334
(Assignee)

Comment 7

16 years ago
Created attachment 66770 [details] [diff] [review]
Updated patch for Unix static build

I learned in static build mode, we will be required to link with NSS
dynamically, too.
Attachment #65990 - Attachment is obsolete: true

Comment 8

16 years ago
Comment on attachment 66770 [details] [diff] [review]
Updated patch for Unix static build

r=wtc.
Attachment #66770 - Flags: review+
(Assignee)

Comment 9

16 years ago
The patch from this bug is now contained in 116334 and has been reviewed by seawood.

*** This bug has been marked as a duplicate of 116334 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 10

16 years ago
Verified dupe.
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.2 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.