FYI: projects update.

DJ Lucas dj at
Thu Jul 30 16:33:54 PDT 2009

Ken Moffat wrote:

>  I gave up trying to build XUL and FF (3.5) without separate nss, nspr.
> FF
> couldn't find nspr or nss.  Hacked the XUL build to install the nss-config
> that
> it creates, but the nspr tests in FF's configure still couldn't find
> prlog.h. So,
> I editednss-config to pass the sdkdir as well (I'm using a fedora patch,
> so it
> is called xulrunner-sdk-, without that it's probably still
> xulrunner-devel-) : that
> worked for nspr (although I don't fancy trying to generate the correct XUL
> version automatically), but FF's configure then decided I didn't have
> system
> nss and presumably built its own again.  Didn't try to use that version
> cos it
> plainly wasn't built how I wanted.

You went further than I did.  I copied the premade files into the root of
the source directory for xulrunner, and ended the installation with:

ln -vsf mozilla-nss.pc /usr/bin/nss.pc &&
ln -vsf mozilla-nspr.pc /usr/bin/nspr.pc &&
install -m755 nss-config /usr/bin/nss-config &&
install -m755 nspr-config /usr/bin/nspr-config

> Went for separate nspr and nss, each with -config and .pc (e.g. epiphany
> uses, or used to use, nspr.pc).  Apart from the hoops we have to jump
> through to build these, it built ok.

I personally still feel that this is a waste to build separate nss and
nspr.  No matter what, Xulrunner has to be rebuilt if you install new
nss...I don't remember off the top of my head, but I think if for nspr
too, should you separate them.  All three go hand in hand.  I suppose,
however, the same could be said for firefox (though the rebuild isn't
strictly necessary), which I do build separately.  IDK, we'll see how it
pans out.  Maybe I will build all separately.

> But, this testing was in directories
> below
> /opt.  For the nspr-nss-XUL-FF build I can only run firefox if I pass
> LD_LIBRARY_PATH, otherwise I get the ubiquitous 'Failed to load XPCOM'
> message.  Strace showed it was looking for, but only in /usr/lib
> -
> the library is actually under $PREFIX/lib/xulrunner-  I'm hopeful
> this will just work when I build it in /usr.

Hmm...-rpath-link in CFLAGS for nss-config?  I don't recall exactly how
-rpath{,-link} work off the top of my head, and no time to look it up ATM
(I'm already late).  But here is what I have quick:

dj [ /sources ]$ nss-config --cflags
dj [ /sources ]$ nss-config --libs
-Wl,-rpath-link,/usr/lib -L/usr/lib -lssl3 -lsmime3 -lnss3
dj [ /sources ]$ nspr-config --cflags
dj [ /sources ]$ nspr-config --libs
-L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl
dj [ /sources ]$ pkg-config --libs nss
-L/usr/lib/xulrunner-devel- -lnss3 -lnssutil3 -lsmime3 -lssl3
-lsoftokn3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl
dj [ /sources ]$ pkg-config --cflags nss
dj [ /sources ]$ pkg-config --libs nspr
-L/usr/lib/xulrunner-devel- -lplds4 -lplc4 -lnspr4 -lpthread -ldl
dj [ /sources ]$ pkg-config --cflags nspr
dj [ /sources ]$ nss-config --version
dj [ /sources ]$ nspr-config --version
dj [ /sources ]$ pkg-config --modversion nss
dj [ /sources ]$ pkg-config --modversion nspr
dj [ /sources ]$

nss.pc looks bad there.  Fortunately, the check is pkg-config ignorant and
depends only on nss-config...looking at the logs:

dj [ /sources ]$ grep NSS logs/079-firefox-3.5.1
checking for NSS - version >= 3.12.0... yes
dj [ /sources ]$

So had better install a new nss.pc file too, instead of the symlink.

>  Agree about the "packaging" warnings, ISTR mozilla packages have always
> had a tendency to spew this sort of message.

Guess I just never noticed it.

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the blfs-dev mailing list