You really shouldn't need this section, because ideally you should be able to get everything in tidy packages for your system. There are always some who want to do it themselves, though. This is a representative list of the questions that come up the most commonly. In what order do I compile the packages? This order has been reported to work well: Compile glib. Compile gtk+. Compile imlib. Compile ORBit. Compile audiofile. Compile esound. Compile libxml. Compile gnome-libs. Compile gdk-pixbuf. Compile libghttp. Compile libglade. Compile libgtop. Compile gnome-print. Compile control-center. Compile gnome-core. After this, the order is less important. You should be able to compile the remaining GNOME applications in any order. If you want to experiment with Evolution and/or Nautilus, two applications which are not yet part of the standard GNOME distribution, you will need to download and compile gconf, oaf, popt and bonobo as well. All of these will eventually be part of GNOME, but they are not part of it yet. That's all very well but how do I compile a tarball? If you have an rpm-based system, skip this question and go to the section about generating rpms from tarballs. It saves a lot of trouble to do with putting files into the right places for your system. If not, the standard way to compile gnome tarballs is to issue the following commands as a normal user: Unpack the tarball and cd into the top of the tarball directory. ./configure make This is a good time to test the program to check it's working before doing the next stage. su make install If you want to be able to remove the program neatly later, do not delete all the files in that directory. This will allow you to do make uninstall at a later date. See the question about uninstalling for details. That will put your tarball into /usr/local/, which is where programs you compile locally should go. If you want it somewhere different, then you should either get the package in the same format that the rest of your package management system uses, so that it can go with the rest; or you need to pass the ./configure some extra arguments telling it where it should go. These arguments are generally --prefix and --sysconfdir. Some people also advocate --localstatedir and --datadir. Please re-read the first sentence of the previous paragraph. Programs you compile locally should go in /usr/local/. Mixing binaries provided by a package management system (rpm, dpkg) with binaries from locally-compiled source into the same directory such as /usr/ is not universally recommended. My system has GNOME in one part of the filesystem. How do I make sure my newly-compiled packages end up in the same place? By default, tarballs you build and compile yourself will be placed in /usr/local. This is not always where you want them, because then if you use package management then later RPMs or debs may not see the programs in /usr/local/. There is a very strong school of thought which says that you should not be muddling up packages installed from different methods into the same directories because it will confuse things badly. If you use rpms you can create rpms from tarballs of most GNOME packages as described below. That said, different distributions use different combinations of prefixes. The way to find out what GNOME is expecting on your machine is to type gnome-config --prefix and gnome-config --sysconfdir. You can then use the results when you do ./configure by giving it arguments: for example, ./configure --prefix=/usr --sysconfdir=/etc. You can even show off by making use of backticks and doing ./configure --prefix=`gnome-config --prefix` --sysconfdir `gnome-config --sysconfdir` all in one line. You can get a complete list of all the arguments you can give to configure by typing ./configure --help. If you must do this, these are the combinations you are probably looking for: OS --prefix --sysconfdir Notes Red Hat Linux /usr /etc Debian GNU/Linux /usr /etc Caldera OpenLinux /opt/gnome /etc/opt/gnome Helix GNOME uses /opt/gnome/etc for sysconfdir SuSE Linux /opt/gnome /etc/opt/gnome Linux Mandrake /usr /etc Solaris /opt/gnome Helix GNOME uses /opt/gnome/etc for sysconfdir I have a perfectly fine GNOME installation, but I want to try some of the newer packages without blowing away my working set-up. Can I compile a newer set of GNOME packages into a particular area? How do I do this? Yes, you can. The most sensible approach is to compile it yourself into an area in your own home directory. Doing this as your normal user rather than root means that you're not going to overwrite working system binaries. cd (go to home directory) tar xvfz gnome-package.tar.gz (unpack a package) cd gnome-package (into that directory) ./configure --prefix=~/gnome --sysconfdir=~/gnome/etc (note the ~ sign in each prefix. Don't miss this out!) make (compile it. This is the longest stage) make install (put it where the next programs will see it) cd ~/gnome/bin (this is where it should have ended up) ./gnome-app (try it out) The above will work for most things but you may have problems with applets, which expect to see a file called /etc/CORBA/servers. You can probably create a symlink from your home directory to this, but your writer hasn't tried. My system is RPM-based. What do I do with tarballs? You can create an RPM from a tarball if the tarball contains a valid specfile. Many GNOME packages do. As root, run rpm -tb <tarballname> to create a binary rpm, or rpm -ta <tarballname> to create both a binary and a source rpm. If there is no specfile in the tarball, it is not unknown for people to post their homemade specfiles to the gnome-list mailing list or to Gnotices. You can take a separate specfile and do one of two things with it: Option one: as root, place the tarball of package foo in the SOURCES directory and the specfile in the SPECS directory of /usr/src/redhat/, change to the SPECS directory, and run rpm -ba foo.spec. You may need to replace redhat with the appropriate directory name for your distribution. This will be whatever sub-directory there is besides the one called linux. Option two: untar your tarball with tar xvfz foo.tar.gz, place the specfile into the resulting directory, and retar it up with tar cvfz foo.tar.gz foo/*. Then become root, and run rpm -ta on the resulting new tarball. I have problems building RPMs from tarballs because it can't find locales correctly. Run this command before building the rpm: unset LINGUAS. It should work now. You may want to add this to the %build section of the specfile instead. Some people have suggested that you may wish to unset LANGUAGE, LANG and LC_ALL as well. I need db2html to build some of the help files. What is it and where can I get it? db2html is a script which invokes jade or openjade. The packaging of the DocBook tools varies with OS and distribution. On Red Hat and some other distributions, it is found in the stylesheets package. On other systems, it may be part of a different DocBook-related package. The current collection of packages is sgml-common, docbook, jade (or openjade) and stylesheets (or cygnus-stylesheets). If you want to produce PostScript documentation you will also want the jadetex package. A new set of tools called docbook-utils is also in creation. The canonical source for DocBook tools is the Cygnus docbook tools website and associated ftp archive, both of which are now hosted by Red Hat; but the tools are increasingly being provided by the major Linux and BSD distributions. Check your vendor's FTP site. GNOME uses DocBook a lot for documentation and you can find lots of information about it on the Gnome Documentation Project pages. I have DocBook correctly installed but when I build a package I get errors as the documentation sections get built. GNOME has an extra stylesheet and a DTD which it uses for documents which use graphics. These enable us to use PNG graphics instead of GIFs. In big package releases, the maintainers will make sure the docs are already built. In some tarballs, though, this doesn't always happen. These are generally the tarballs which aren't meant for stable production release where it's expected the people playing with them will know what is going on with this message. If you meet it, you have a couple of choices: After ./configure and before make, edit the file Makefile.am and remove "docs" from the line beginning "SUBDIRS". This will mean the docs just won't get built. Change the DTD (the line in angle-brackets). Alter "-//GNOME//DTD DocBook PNG Variant V1.1//EN" to read "-//OASIS//DTD DocBook V3.1//EN" in all files that have the suffix .sgml. If you want to, remove all the sections which appear to look like graphics (easily identified by being surrounded by the <figure> and </figure> tags. This will build the docs without the graphics (or with broken links if you leave them in). Get the GNOME DTD and stylesheets and install them. They are available as a tarball, a deb or an rpm, or the individual components from Dave Mason's page. Then it should build. I have installed all the base packages from the ftp site, but when I start to compile something else, I am told I am missing a headerfile with a message like this: Cannot find gnome-libs or somefile.h: not found. This affects people who install binary rpms or debs. It does not affect people using tarballs, source rpms or debs with the source. Binary packages come in two sorts. There are the ones which come with names of the form <package>.suffix, and there are the ones with the form <package-dev>.suffix or <package-devel>.suffix. (SuSE, using eight-letter package names, often abbreviates them further to such forms as <pkgdev>.suffix or even <pkgd>.suffix.) The first sort are what you need to run the programs in the package and are generally called the base packages on ftp sites. The second sort are what you need in addition if you want to compile and install new programs that rely on other programs' code. They contain header files which the new programs you want to compile will look for. If you expect to be compiling the occasional tarball (or generating rpms from tarballs), collect gnome-core-devel, gnome-libs-devel and so on binaries and install them in addition to the base packages. gnome-libs won't compile on Solaris 2.6. It fails with a complaint about Berkeley DB lacking DB 1.85 compatibility. Berkeley DB versions later than 2.7.7 (3 and up, basically) apparently break compatability with v1.85. Either get 2.7.7 or have a look at the patch to db_185.h which is found on the postfix FAQ. You will still need to tinker with configuration scripts after applying this patch, though. Also check out Paul Barnfeather's Building GNOME on Solaris page for more Solaris hints. How do I uninstall something I installed? With rpm: rpm --erase package. With dpkg: either dpkg --remove package apt-get remove package Or dpkg --purge package apt-get remove --purge package You should probably use apt-get because it will automatically figure out dependencies. The --purge for each command will remove configuration files as well. With tarballs: you must previously have kept the source tree. Change to the directory containing it, run make uninstall and hope someone wrote the rule which will do this for you.