Firefox 6 für FreeBSD

[Fusselbär]

Hallo,

heise.de hat über Sicherheitslücken in Firefox 5 berichtet:
http://www.heise.de/open/meldung/Moz...y-1324603.html
In den FreeBSD Ports ist der Firefox 6 verfügbar:
http://www.freshports.org/www/firefox/

Es traten jedoch bei einigen Benutzern Probleme beim Firefox 6 compilern auf:
http://www.freebsd.org/cgi/query-pr.cgi?pr=159831
Auch auf meiner FreeBSD 8.2-STABLE amd64 Installation war das zunächst der Fall.
Besonders hilfreich war der Hinweis von Anthony Jenkins:

I had the same problem here, it seems the firefox-6.0 build is pulling
jstypes.h from the base system (/usr/local/include) and that header file
does not define JS_ALWAYS_INLINE. I had 3 instances of this header
under /usr/local/include from libxul, firefox4 and some dependent port
of mediatomb's. I uninstalled libxul & the mediatomb one and renamed
/usr/local/include/firefox to firefox.bak, restarted the firefox upgrade
and it looks like the build works again. I believe the port needs to
move the inclusion of /usr/local/include/* directories after the ones
under /usr/ports/www/firefox/work, at least in this subdirectory of the
firefox-6 source tree.

Bei mir waren an jstypes.h Header Dateien folgende vorhanden:

locate jstypes.h
/usr/local/include/firefox/jstypes.h
/usr/local/include/jstypes.h
/usr/local/include/libxul/jstypes.h

JS_ALWAYS_INLINE war nur in:

/usr/local/include/firefox/jstypes.h
/usr/local/include/libxul/jstypes.h

zu finden.
Trotzdem brachte das entfernen von libxul und firefox zunächst bei mir nicht den gewünschten Erfolg,
schlussendlich muss es bei mir an spidermonkey gehangen haben,
denn der hatte sein jstypes.h in:

/usr/local/include/jstypes.h

Nachdem ich dann lang/spidermonkey deinstalliert hatte, baute auch Firefox 6 durch.

Das gebaute 64 Bit Firefox 6 Fertigpakt für FreeBSD 8.2-STABLE amd64 habe ich auf einen One Klick Hoster hoch geladen, falls es jemand haben möchte:
http://netload.in/dateiBfxgBGDNtc/firefox-6.0,1.tbz.htm
Die sha256 Checksumme vom firefox-6.0,1.tbz

SHA256 (firefox-6.0,1.tbz) = cda55a1ec73ef5967b9aa6ea34ea8df8a370beeaa774c7892185ac4c6cdbb140

Das firefox-6.0,1 Fertigpaket wurde auf einem FreeBSD 8.2-STABLE amd64
mit folgenden Optionen gebaut:

cat /var/db/ports/firefox/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for firefox-6.0,1
_OPTIONS_READ=firefox-6.0,1
WITH_DBUS=true
WITH_PGO=true
WITHOUT_DEBUG=true
WITHOUT_LOGGING=true
WITH_OPTIMIZED_CFLAGS=true

Die Firefox Addon Kompatibilitätsprüfung lässt sich wie üblich über about:config mit folgenden Boolean Schlüssel generieren ausschalten:

extensions.checkCompatibility.6.0

Diesen extensions.checkCompatibility.6.0 Boolean Schlüssel dann auf false stellen.

[Tron]

Mir würde es vorerst schon reichen, falls Firefox 4/5/6 (und Thunderbird 6) auf einer meiner Kisten (Athlon XP und für FF/TB wohl auch zu magere 1GB RAM) nicht sofort mit illegal instruction den Dienst quittieren würde.
Auch nicht schlecht wäre, wenn beim Schließen von FF3/TB3 nicht nur das Fenster verschwinden würde, sondern sich tatsächlich auch der Prozess beenden würde.
Aber was sind schon solche abwegigen Ansprüche verglichen mit höheren Versionsnummern (oder bald gar keine mehr!) und bunterem Klicki.

[Fusselbär]

Ist das sem Modul geladen?

Zitat von UPDATING

20090628:
AFFECTS: users of www/firefox3-devel
AUTHOR: gecko@FreeBSD.org

If your Firefox crashes with the following message while viewing a
HTML5 page: "Bad system call (core dumped)" you need to load the sem
module (kldload sem).

To load sem module on every boot, put the following into your
/boot/loader.conf:

sem_load="YES"

[Tron]

Ja, ist es. FF3 läuft (der UPDATING-Eintrag gilt ja schon seit dann) und ich sehe auch nicht "bad system call", sondern "illegal instruction".
Ich vermute, die FF-Frickler setzen hart irgendwo -msse2 oder sowas. Ich muss da mal auseinander nehmen.