that when they are dlopen()'ed they can tell ld.so where to go hunt for
the other mozilla libs they depend on.
Similar fix as done in xulrunner 1.8 patch-config_rules_mk 2 years ago
by martynas@, needed to convert py-gnome-extras to xulrunner 1.9.
No fallout on firefox.
symlink libxpcomglue{,_s}_pic.a to libxpcomglue{,_s}.a so that #@#@!@$
libtool correctly links with the xpcom glue. Adjust libxul{-embedding}.pc
to return the appropriate _pic lib.
- mozilla don't do real releases anymore from xulrunner itself, so build
it from firefox 3.6.3 tarball. Thx tnn@netbsd for the trick.
- that also permits us to use patches/ and files/ from
www/mozilla-firefox, and stop mirroring another 50Mb distfile. Yay!
- some headers are MI, so do the PFRAG.{amd64,jit}-devel dance in PLIST
sthen@ thinks 'going in this direction makes a lot of sense'.
corresponding to ffx 3.5.x. Most patches taken from there, tested
successfully @ppc/amd64/sparc64. Branch 1.9.0.x is approaching attic
upstream, as ffx 3.0.x.
The plan is to move all users of xulrunner/1.8 to use this latest
version, and then ditch the old unmaintained one from ffx 2.x days.
MFSA 2009-44 Location bar and SSL indicator spoofing via window.open()
on invalid URL
MFSA 2009-43 Heap overflow in certificate regexp parsing
MFSA 2009-42 Compromise of SSL-protected communication
xulrunners. this was necessary for smooth migration, since we want
plugins work for mozilla 1.8 branch too (seamonkey, thunderbird);
they are upwards-compatible if built against 1.8. however, some
new applications started to depend on 1.9, and also other (non-plugin)
apps will start to migrate so that the old xulrunner can go away
requested by many; bulk build & pkgpath & bump done by sthen@
