Making The GNOME Shell Works Again

15 Feb 2012

GNOME LogoThis time, I would say that I can beat GNOME Shell trouble related with recent seamonkey package upgrade in Slackware. For your information, the current gjs package of GNOME SlackBuild which is used by gnome-shell to render its javascript code was linked against seamonkey 2.5. Sadly, seamonkey version 2.5 and 2.7 have some API differences, including the seamonkey javascript. engine which used by gjs library. And as expected, an upgrade from 2.5 to 2.7 will break the gjs funcionality and resulting crashes to gnome-shell. If you look into bug reports about gjs and seamonkey in GSB Users Discussion, you'll find that you are not alone in this case.

So how about rebuild the gjs package against seamonkey 2.7? Some attempt to rebuild gjs package to use seamonkey 2.7 were not success at all. The js API that being used within gjs were not compatible with seamonkey 2.7. So it will make the compilation failed. There are still no patches or fix from gjs developer (GNOME developer) about this API changes. So it must be another way to make gnome-shell works again.

Several days ago, I accidentally take a look the configure script of gjs and just found out that gjs could be compiled against mozjs185. Mozjs185 itself is a pkg-config name for SpiderMonkey. Some words about SpiderMonkey from Wikipedia:

SpiderMonkey is the code name for the first-ever JavaScript engine, written by Brendan Eich at Netscape Communications, later released as open source and now maintained by the Mozilla Foundation. SpiderMonkey currently provides JavaScript support for Mozilla Firefox and various embeddings such as the GNOME 3 desktop.

No. Your eyes were not wrong. SpiderMonkey was indeed used by GNOME 3. I have seen several distro like opensuse were using mozjs185 (SpiderMonkey) for GNOME 3 javascript engine.

So without anymore doubt, I am finally rebuild my gjs package against mozjs185 which I have already use for the 0ad game package. At first built, I have derived the opensuse mozjs185.spec configuration. And later on, I got an email reply from Robby Workman about his works on mozjs185 (Robby uses a name of js185) and I rebuilding my mozjs185 package using his slackbuild configuration with some modification. Robby's SlackBuild is using additional nspr library which is built and installed before building mozjs185. So Robby's js185.SlackBuild is using --with-system-nspr option. I prefer to preserving the compatibility with slackware by using seamonkey nspr library. So I am using these options to build the mozjs185:

  --enable-threadsafe \
  --with-nspr-cflags="`pkg-config --cflags nspr`" \
  --with-nspr-libs="`pkg-config --libs nspr`"

After rebuilding and installing mozjs185, I had to rebuild gjs and gnome-shell package to use mozjs185 library instead of seamonkey javascript library. After that could start the gnome-shell and using it to wrote this blog post.

GNOME Shell using Mozjs185 (SpiderMonkey)

So that's my solution for the gnome-shell versus seamonkey troubles. How about you?