## Tuesday, September 22, 2009

### Google Chrome (Chromium) for RHEL (CentOS) 5

For a long time, I've kept a Windows machine for Remote Desktop access that I use just so that I can use Google Chrome. The reason is that editing Google Sites pages, for example, drags Firefox 3.5 and Opera 10 to a slow crawl. And Firefox 3.5 on Linux (since beta2) crashes my X11 server because the video driver (xorg-intel) is old and buggy. But I've long wished to abandon Windows altogether. I share the Windows machine with another graduate student, and the Windows Server 2003 license for that computer restricts two remote desktop connections. This is surely absurd for me as a Linux user because I've along accustomed to unlimited number of connections (subject only to resource availability as opposed to artificial license restriction). Granted, I could have used VNC, but it's not as responsive.

It is currently not my best interest to figure out how to compile Chrome from scratch (they appear to be using some gclient custom build tools). However, the precompiled binary snapshots require more recent versions of FreeType, Gtk+, and NSS (network security service, as part of Mozilla) than that available on BU Linux (which is a RHEL/CentOS 5 derivative).

Compiling Gtk+ is a nightmare because of the sheer number of dependencies. Here I'm listing the packages I need. The listing format is "target: dependencies"
• gtk+: atk glib cairo pango jasper fontconfig
• pango: cairo freetype glib
• cairo: libpng freetype pixman fontconfig
• fontconfig: freetype
• atk: glib
• glib:
• libpng:
• freetype:
• pixman:
• jasper:
The order listed above is in reverse topological order. I just put them in a Makefile and let make figure out the order for me. Fortunately, these packages are standard GNU autoconf/automake based. You will have to set export variables as follows:
• PREFIX := ... # you pick a convenient location
• export CFLAGS := ... # you pick the compilation options, e.g. -march=i686 -O3
• export CPPFLAGS := -I$(PREFIX)/include • export LDFLAGS := -L$(PREFIX)/lib
• export PKG_CONFIG_LIBDIR := $(PREFIX)/lib/pkgconfig • export PATH :=$(PREFIX)/bin:$(PATH) • export LD_LIBRARY_PATH :=$(PREFIX)/lib
You will have to run configure with --prefix=$(PREFIX), and then run make and make install inside your Makefile. I also wrote a script to essentially do the following. This will be left as an exercise to the reader. • Given a target name like gtk+, locate the source package tar.gz and unpack it. • Make a new object files directory and run the configure script there as the current working directory. If the build fails, you can just remove the object directory to get a clean slate, instead of needing to unpack the source files again. • Do the traditional make and make install. • Touch the target as a file, so make doesn't have to repeat building and installing a target if it already succeeded. Each rule in the Makefile would look like this: # Assuming the build script is called build.sh in the current directory. BUILD := ./build.sh gtk+: export LDFLAGS := -lm # for jasper gtk+: atk glib cairo pango jasper fontconfig$(BUILD) \$@
On the other hand, NSS has its own build instruction, so I did it manually. The resulting nss shared objects must be symlinked in a particular way:
• Add ".1d" suffix: libnss3, libnssutil3, libsmime3, libssl3.
• Add ".0d" suffix: libplds4, libplc4, libnspr4.
I imagine that's Ubuntu/Debian convention.

I also compiled my own gcc 4.3/4.4, and without a recent gcc and libstdc++.so.6, you will get a dynamic linking error with the symbol GLIBCXX_X_Y_Z.