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?
It should; it would be quite weird for it not to (even more so than this bug).
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).
Created attachment 68354 [details] [diff] [review] Suggested fix 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?
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.
This will work for OS/2. Once bug 114748 is checked in, we can also get rid of NSS_LIB_PREFIX.
Comment on attachment 68354 [details] [diff] [review] Suggested fix email@example.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+
Who should do additional review of the makefile changes, or can this go in?
Looks fine to me (other than that entire block should be moved to config.mk so that this doesn't break in static builds).
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.
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).
*** Bug 125524 has been marked as a duplicate of this bug. ***
Since this breaks BSD builds, raising priority. We have a close-to-complete patch....
Severity: normal → critical
Keywords: mozilla0.9.9, patch
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"
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.
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.
The patch did fix things. but a recent checkin regarding nss target seemed to break this patch.
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.
Created attachment 69723 [details] [diff] [review] Updated patch Note: comments above say this may still not fix static builds. I'll check into that after this goes in.
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.
Cls would you sr=? Kai can you review?
Priority: -- → P1
Target Milestone: --- → 2.2
Created attachment 69768 [details] [diff] [review] Remove duplicate NSS_LIBS defines and handle static build case
Attachment #69723 - Attachment is obsolete: true
Much cleaner, thanks. firstname.lastname@example.org Let's get this in!
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+
The patch (with Wan-Teh's suggestion) has been checked in. Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.