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

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P1)

Description

[Kai Engert [:KaiE:]]

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

[Randell Jesup [:jesup] (needinfo me)]

It should; it would be quite weird for it not to (even more so than this bug).

Comment 2

[Kai Engert [:KaiE:]]

CC'ing more people, FYI

Comment 3

[Jim Dunn]

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

Comment 4

[Kai Engert [:KaiE:]]

Attachment: 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

[Wan-Teh Chang]

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

[jhp (no longer active)]

This will work for OS/2.  Once bug 114748 is checked in, we can also get rid of
NSS_LIB_PREFIX.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 68354 [details] [diff] [review]
Suggested fix

r=[e-mail] 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

Comment 8

[Kai Engert [:KaiE:]]

Who should do additional review of the makefile changes, or can this go in?

Comment 9

[hacker formerly known as [e-mail]]

Looks fine to me (other than that entire block should be moved to config.mk so
that this doesn't break in static builds).

Comment 10

[Kai Engert [:KaiE:]]

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

[hacker formerly known as [e-mail]]

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

[hacker formerly known as [e-mail]]

*** Bug 125524 has been marked as a duplicate of this bug. ***

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Since this breaks BSD builds, raising priority.  We have a close-to-complete
patch....

Comment 14

[timeless]

changing summary so i can find this bug :-(

Comment 15

[Stephane Saux]

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

[Jim Dunn]

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

[clkao]

The patch did fix things. but a recent checkin regarding nss target seemed to
break this patch.

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

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

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Updated patch

Note: comments above say this may still not fix static builds.	I'll check into
that after this goes in.

Comment 20

[Jens Fallesen]

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

[Stephane Saux]

Cls would you sr=?
Kai can you review?

Comment 22

[hacker formerly known as [e-mail]]

Attachment: Remove duplicate NSS_LIBS defines and handle static build case

Comment 23

[Randell Jesup [:jesup] (needinfo me)]

Much cleaner, thanks.  r=[e-mail]
Let's get this in!

Comment 24

[Wan-Teh Chang]

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.

Comment 25

[hacker formerly known as [e-mail]]

The patch (with Wan-Teh's suggestion) has been checked in.  Marking fixed.

Comment 26

[John Unruh]

Verified.