Runtime link failures on FreeBSD -- Load FAILED with error: Cannot open "../../../../dist/lib/"



17 years ago
2 years ago


(Reporter: kaie, Assigned: kaie)


Other Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)



17 years ago
Jesup reported problems on FreeBSD. During startup, he sees
Load FAILED with error: Cannot open "../../../../dist/lib/"

We saw that our link commands for are nearly identical on Linux and
FreeBSD. But we list the shared objects with relative pathnames (e.g.

While that works on Linux, and the resulting only has a reference
to a file named "", the FreeBSD library includes that path, and when
started, tries to access that library using the relative patch - which does not

The suggestion is to use the alternative link command in the form
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).

Comment 2

17 years ago
CC'ing more people, FYI

Comment 3

17 years ago
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 or

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).  

Comment 4

17 years ago
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?

Comment 5

17 years ago

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
Comment on attachment 68354 [details] [diff] [review]
Suggested fix 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+

Comment 8

17 years ago
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 so
that this doesn't break in static builds).

Comment 10

17 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/, 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
Severity: normal → critical
Keywords: mozilla0.9.9, patch

Comment 14

17 years ago
changing summary so i can find this bug :-(
Summary: Runtime link failures on FreeBSD → Runtime link failures on FreeBSD -- Load FAILED with error: Cannot open "../../../../dist/lib/"

Comment 15

17 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

17 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

17 years ago
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.


17 years ago
Attachment #68354 - Attachment is obsolete: true

Comment 20

17 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

17 years ago
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


17 years ago
Blocks: 123917
Much cleaner, thanks.
Let's get this in!

Comment 24

17 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/

>-ifdef NSS_3_4
> DEFINES += -DNSS_3_4

I suggest that we say, instead:

 NSS_3_4 = 1

 ifdef NSS_3_4

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.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago


14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.