For new readers: with the release fo firefox3, building the browser
app ('firefox') does not install pkgconfig files.  Building it as
xulrunner does; you then have to build it again as firefox, with a
switch pointing to the xulrunner sdk libs (fortunately, the second
build is quick).

 We had some discussion about where nss and nspr fit in, with a view
that the versions shipped with firefox should be current.

 In my current build, I'm using xulrunner to provide nss and nspr.
Unfortunately, I overlooked that the static libraries are now in
/usr/lib/xulrunner-devel-1.9.0.6/{,sdk/lib} (hardlinks) so my
grand scheme (to hide all the static libs, until I found *which*
were being used by *what* - more to follow in a separate post) came
to nothing as far as libcrmf and any similar libs are concerned).

 I'm using the following fix from Simon Geard, I don't remember
which package needs it (it's probably in the blfs-support archives)
echo "Requires: nspr" >>xulrunner/installer/libxul-embedding.pc.in

 I managed to build the following using nss and/or nspr and/or gecko
from xulrunner: yelp, epiphany, evolution-data-server, totem-pl,
totem.  There are the following issues:

1. Yelp only looks for nspr.pc, but the file installed by xulrunner
is mozilla-nspr.pc.  A symlink fixes this.  Perhaps something else
might need a similar symlink for nss.pc.

2. The nss and nspr shared libs are in /usr/lib/xulrunner-1.9.0.6
(stripped) - unstripped versions of some of them are also in
/usr/lib/xulrunner-devel-1.9.0.6.  This poses a problem: any program
using them needs to access them at runtime.  Sometimes this shows
during configure when a test script fails (e.g. epiphany), sometimes
it only shows when you try to run the finished program.  Thanks to
Jack Stone on -chat for clarifying my understanding (I thought it
was a link error in the compile, despite
-L/usr/lib/xulrunner-1.9.0.6 being passed).  Anyway, the libraries
need to be found.  I went with a simple solution: put symlinks in
/usr/lib pointing to the current versions of these libs, and do this
at the end of the xulrunner install.  I think I took the idea from
debian, but reversed it - ISTR they move the libs to /usr/lib, and
then create symlinks from xulrunner-x.y.z.

 The key phrase here, IMO, is "current version".  At the moment, the
mozilla browsers seem to get updated on average about once a month,
and each time it's a security update.  Today, the libs are in
xulrunner-1.9.0.6, next time they will be in xulrunner-1.9.0.7.
It's plain to see that we lack resources to keep the book up to
date. I think we should be encouraging users to update regularly, at
least where mozilla releases are concerned, and making sure that
they do it completely.

 There are alternatives:
 we could put the current xulrunner directory into /etc/ld.so.conf
(users then have to remember to delete the old reference and rerun
ldconfig when they update),
 or we could pass LD_LIBRARY_PATH or LD_RUN_PATH when we configure
anything using nss or nspr (nasty - users will have to recompile
with a new xulrunner, although in practice they might have to anyway
- certainly, anything using gecko has to be recompiled).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to