firefox-3.0.7 / xulrunner-1.9.0.7

[ken@…]

With this version, the tarball is shipped under two names (they are identical) and can be built as --enable-application=xulrunner or --enable-application=browser. Building as zulrunner provides the .pc files (but not the browser itself), building as firefox does not provide .pc files.

Various config changes, The xulrunner build needs a one-liner fix from Simon Geard on blfs-support to allow yelp-2.24 to find the prtypes.h header from nspr (if you use system nspr).

echo "Requires: nspr" >>xulrunner/installer/libxul-embedding.pc.in

[ken@…]

Version increase. This time there isn't a separate xulrunner tarball, but the internal version of that has also moved on to 1.9.0.4.

[ken@…]

I've just noticed that it isn't finding the plugins. When building with a separate xulrunner, they are in /usr/lib/xulrunner-1.9.0.4/plugins but firefox looks in /usr/lib/firefox-3.0.4/plugins so a symlink is needed.

[ken@…]

Version increment to 3.0.5, the usual security fixes: Fixed in Firefox 3.0.5 MFSA 2008-69 XSS vulnerabilities in SessionStore MFSA 2008-68 XSS and JavaScript privilege escalation MFSA 2008-67 Escaped null characters ignored by CSS parser MFSA 2008-66 Errors parsing URLs with leading whitespace and control characters MFSA 2008-65 Cross-domain data theft via script redirect error message MFSA 2008-64 XMLHttpRequest 302 response disclosure MFSA 2008-63 User tracking via XUL persist attribute MFSA 2008-60 Crashes with evidence of memory corruption (rv:1.9.0.5/1.8.1.19)

Again, there is no separate xulrunner, but I see that xulrunner-1.9.0.4 did eventually get released. Confirmed that the internal version of xulrunner is set to 1.9.0.5 (config/autoconf.mk)

[ken@…]

Taking this, per Bruce's request to take what I think I will address in the next couple of months - it will be a while before I do anything on it.

My intention is to use the internal nss, nspr - I think that was the consensus on -dev.

[Randy McMurchy]

Replying to ken@…:

My intention is to use the internal nss, nspr - I think that was the consensus on -dev.

Could you please post a link to that thread?

Or, if you can't find it, what advantage is gained by not using a system-installed NSS/NSPR?

[DJ Lucas]

If you rebuild NSS, due to static linking that is not easily overcome in the arcane coreconf build system, then you need to rebuild xulrunner/firefox. Additionally, Thunderbird and Seamonky (last I checked) had to use the old minor versions of both. Latest security patched releases are included with Firefox, Xulrunner, Thunderbird, and Seamonkey, _always_. We'll have to wait for Thunderbird 3 and new SeaMonky to utilize the system nss/nspr for those projects. Some of the information was contained in a few private emails with George Sherwood (SourceMage maintainer working with the Mozilla projects) whom I was working with at the time. Here is a link to the roundup message where I had given separate build instructions, and later recommended system NSPR with internal NSS for mozy products.

​http://archives.linuxfromscratch.org/mail-archives/blfs-dev/2008-November/019013.html

I'm still not sure what to do about a system NSS for external projects that will use it, which is why I left the instructions for NSS in that message. Anyway, I had thought that there are many messages leading up to that one prior to Novemeber, but I can't seem to find them...I'm probably remembering the private emails. If you'd still like to review them, I'll go back and dig them up, just yell.

[bdubbs@…]

I built FF-3.0.5 without problem, but here are some notes:

The book currently has:

cat >> layout/build/Makefile.in << "EOF" &&
ifdef MOZ_ENABLE_CANVAS
EXTRA_DSO_LDOPTS += $(XLDFLAGS) -lX11 -lXrender
endif
EOF

sed -i "s/^    enum$/& xptinfo_enum_1/" \
    xpcom/reflect/xptinfo/public/xptinfo.h &&

make -f client.mk build

As root:

make -f client.mk install &&

install -v -m755 -d /usr/lib/firefox-2.0.0.15/chrome/icons/default &&
ln -v -s ../../../icons/default.xpm \
    /usr/lib/firefox-2.0.0.15/chrome/icons/default &&

chown -v -R root:root \
    /usr/lib/firefox-2.0.0.15/extensions/inspector@mozilla.org/*

For me the change to layout/build/Makefile.in and xpcom/reflect/xptinfo/public/xptinfo.h were not necessary. The install/ln/chown are also not necessary.

Copying the nss headers is still required.

My .mozconfig looked like:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../firefox-build
ac_add_options --prefix=/usr
ac_add_options --enable-application=browser
ac_add_options --with-system-zlib
ac_add_options --with-system-png
ac_add_options --with-system-jpeg
ac_add_options --enable-system-cairo
ac_add_options --enable-official-branding
ac_add_options --enable-svg
ac_add_options --enable-strip
ac_add_options --disable-dbus
ac_add_options --disable-crashreporter
ac_add_options --disable-tests
ac_add_options --disable-installer
ac_add_options --disable-accessibility
ac_add_options --enable-canvas

d-bus glib bindings and curl (crashreporter) are now optional dependencies. I did not have either installed.

[ken@…]

And the latest bugfixes are out - just when I'd built 1.9.0.5/3.0.6 (withhout system nss/nspr) for a new system.

[ken@…]

Going over 3.0.6, for me the dbus-glib bindings, and python, are now both required - odd. I tried hiding the python executable, and the dbus-glib pkgconfig file - in each case, 'make configure' (the first part of the build) ended in error. I've been building without --enable-strip, I suppose I ought to try that to see what difference it makes - just when I thought I was ready to roll.

[ken@…]

Replying to bdubbs@…:

I built FF-3.0.5 without problem, but here are some notes:

Sorry for the delay replying, I had not spotted all the implications of what you said.

For me the change to layout/build/Makefile.in and xpcom/reflect/xptinfo/public/xptinfo.h were not necessary. The install/ln/chown are also not necessary.

agreed - the 2.0 instructions are somewhat different from what I'm using - I'm not so very different from ​http://www.linuxfromscratch.org/~ken/blfs-kfm-20081108/BOOK/xsoft/firefox.html.

Copying the nss headers is still required.

why ? If you build ff3-as-firefox it only installs the browser, there are no pkgconfig files so common gecko users will not compile against it. Do you have something that uses the conf file in /etc/gre.d ? The only "common" packages doing that seem to be momo and lotus notes.

My .mozconfig looked like:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../firefox-build
ac_add_options --prefix=/usr
ac_add_options --enable-application=browser
ac_add_options --with-system-zlib
ac_add_options --with-system-png
ac_add_options --with-system-jpeg

you used the shipped version of libbz2

ac_add_options --enable-system-cairo

and the shipped version of lcms (that might be necessary on an old system)

ac_add_options --enable-official-branding ac_add_options --enable-svg ac_add_options --enable-strip ac_add_options --disable-dbus

Ah, I missed that option. Will check for it.

ac_add_options --disable-crashreporter ac_add_options --disable-tests ac_add_options --disable-installer

and the updater

ac_add_options --disable-accessibility

ac_add_options --enable-canvas

default, ISTR

[ken@…]

Egg-on-face time: I see I've still got the redundant commands from the ff2 build in the version I referred to. They will be removed, but I'm still curious about why the headers would need to be installed.

[ken@…]

Yet another version update. As usual, the xulrunner tarball has not yet appeared.

[ken@…]

r7804.

[(none)]

Milestone 6.4 deleted