Closed
Bug 124211
Opened 23 years ago
Closed 23 years ago
Runtime link failures on FreeBSD -- libpipnss.so Load FAILED with error: Cannot open "../../../../dist/lib/libsmime3.so"
Categories
(Core Graveyard :: Security: UI, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.2
People
(Reporter: KaiE, Assigned: KaiE)
References
Details
Attachments
(1 file, 2 obsolete files)
Jesup reported problems on FreeBSD. During startup, he sees nsNativeComponentLoader: SelfRegisterDll(/home/jesup/src/mozilla_work/mozilla/obj-i386-unknown-freebsd4.3/dist/bin/components/libpipnss.so) Load FAILED with error: Cannot open "../../../../dist/lib/libsmime3.so" We saw that our link commands for libpipnss.so are nearly identical on Linux and FreeBSD. But we list the shared objects with relative pathnames (e.g. ../../../../dist/lib/libsmime3.so). While that works on Linux, and the resulting libpipnss.so only has a reference to a file named "libsmime3.so", the FreeBSD library includes that path, and when started, tries to access that library using the relative patch - which does not work. The suggestion is to use the alternative link command in the form -lsmime3 instead. This works on Linux, too. Does somebody know if this approach works on all UNIX variants?
Comment 1•23 years ago
|
||
It should; it would be quite weird for it not to (even more so than this bug).
Assignee | ||
Comment 2•23 years ago
|
||
CC'ing more people, FYI
Yes this will work on all unix variants... there is some name issues with os/2 but Mike I think has taken care of that in rules.mk or config.mk. I had just noticed this also... the use of lib<blah>.so and doing the "-L<dir> -l<blah>" is the preferred solution for mozilla (and hopefully nss).
Assignee | ||
Comment 4•23 years ago
|
||
As we now have a difference between the link command and the list of dependent libraries, a bigger changes was necessary. Or can we simplify this patch more, because the -l<name> syntax will work on gmake based builds on OS/2 and WINNT, too?
Comment 5•23 years ago
|
||
Kai, I have to admit I noticed this too while reviewing the NSS 3.4 landing patch and in fact I know this is not portable. I agree that "-L<dir> -l<blah>" is the right solution.
Comment 6•23 years ago
|
||
This will work for OS/2. Once bug 114748 is checked in, we can also get rid of NSS_LIB_PREFIX.
Comment 7•23 years ago
|
||
Comment on attachment 68354 [details] [diff] [review] Suggested fix r=rjesup@wgate.com for FreeBSD/Linux - it sounds like the OS/2 changes mentioned are optional but perhaps should be done. Let's PLEASE get this in ASAP since this breaks BSD. I imagine otaku would show red if it wasn't missing from the ports tinderbox
Attachment #68354 -
Flags: review+
Assignee | ||
Comment 8•23 years ago
|
||
Who should do additional review of the makefile changes, or can this go in?
Comment 9•23 years ago
|
||
Looks fine to me (other than that entire block should be moved to config.mk so that this doesn't break in static builds).
Assignee | ||
Comment 10•23 years ago
|
||
I don't know how the static build system works. However, I thought this patch will not break the static build, because the static build currently works, and we have a separate definition of NSS_LIBS in config/config.mk, which has a comment that says it is for the static build.
Comment 11•23 years ago
|
||
This patch won't break the existing non-FreeBSD static builds but it also doesn't fix the relative link problem for FreeBSD static builds. We should have just a single NSS_LIBS definition that is used to link both PSM & the various static build targets (mozilla-bin & embedding apps).
Comment 12•23 years ago
|
||
*** Bug 125524 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
Since this breaks BSD builds, raising priority. We have a close-to-complete patch....
Severity: normal → critical
Keywords: mozilla0.9.9,
patch
Comment 14•23 years ago
|
||
changing summary so i can find this bug :-(
Summary: Runtime link failures on FreeBSD → Runtime link failures on FreeBSD -- libpipnss.so Load FAILED with error: Cannot open "../../../../dist/lib/libsmime3.so"
Comment 15•23 years ago
|
||
Kai, do you know how to fix this? If not, work with the FreeBSD experts to produce a patch that will work. We don't have a FreeBSD environment here. We welcome a patch from anybody who has.
Comment 16•23 years ago
|
||
Stephane, Kai's patch is already mentioned Created an attachment (id=68354) This work on AIX (where we have a similar problem). I am not sure what is holding this up from being checked in.
Comment 17•23 years ago
|
||
The patch did fix things. but a recent checkin regarding nss target seemed to break this patch.
Comment 18•23 years ago
|
||
This patch can be trivially applied to the trunk from examining it. The only change to the trunk that affects this is changing NSS_LIB_PREFIX to LIB_PREFIX on the crmf dependency line. I'll post an updated patch.
Comment 19•23 years ago
|
||
Note: comments above say this may still not fix static builds. I'll check into that after this goes in.
Updated•23 years ago
|
Attachment #68354 -
Attachment is obsolete: true
Comment 20•23 years ago
|
||
I just tried to pull the latest tree and apply the patch in attachment 69723 [details] [diff] [review] on my FreeBSD system. This works just fine.
Comment 21•23 years ago
|
||
Cls would you sr=? Kai can you review?
Priority: -- → P1
Target Milestone: --- → 2.2
Comment 22•23 years ago
|
||
Attachment #69723 -
Attachment is obsolete: true
Comment 23•23 years ago
|
||
Much cleaner, thanks. r=rjesup@wgate.com Let's get this in!
Comment 24•23 years ago
|
||
Comment on attachment 69768 [details] [diff] [review] Remove duplicate NSS_LIBS defines and handle static build case This patch looks good. I suggest one change. In security/manager/ssl/src/Makefile.in: >-NSS_3_4=1 >- >-ifdef NSS_3_4 > DEFINES += -DNSS_3_4 >- I suggest that we say, instead: NSS_3_4 = 1 ifdef NSS_3_4 DEFINES += -DNSS_3_4 +endif This will make it clear that -DNSS_3_4 should also be removed when we remove the non-NSS 3.4 code.
Attachment #69768 -
Flags: needs-work+
Comment 25•23 years ago
|
||
The patch (with Wan-Teh's suggestion) has been checked in. Marking fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•