The following are instructions for building the Second Life viewer on linux. This process has been used on debian and debian based systems like ubuntu, and also on Fedora. For other platforms, see Get source and compile.

Required tools

There are a number of tools that need to be installed first.

cmake [package: cmake]
- Currently (snowglobe 1.3.2 and higher) cmake 2.6.2 is the minimum required version.
yacc or compatible tool [suggested package: bison]
lex or compatible tool [suggested package: flex]
python [package: python]
- python 2.4.3 is the minimum required version.
- All more recent 2.x versions should work, too. If you encounter problems or deprecation warnings, please report them.
- python 3.x hasn't been tested yet.
g++ [package: g++]
- Note (not relevant for standalone): gcc 4.4 (which is in recent Ubuntu and debian) won't work in versions prior to 2.0 (or Snowglobe 1.3) if you are not building standalone (see below), because it chokes on some parts of boost prior to 1.37 (http://svn.boost.org/trac/boost/ticket/2069). The solution is to install GCC 4.3 and to run 'export CXX=/usr/bin/g++-4.3' or whatever your binary is before trying to compile. Another workaround is to use update-alternatives; for example, if you already have 4.4 installed, try this:

sudo apt-get install g++-4.3
sudo update-alternatives --remove-all gcc
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.3 43  --slave /usr/bin/g++ g++ /usr/bin/g++-4.3  --slave /usr/bin/gcov gcov /usr/bin/gcov-4.3
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.4 44  --slave /usr/bin/g++ g++ /usr/bin/g++-4.4  --slave /usr/bin/gcov gcov /usr/bin/gcov-4.4

then choose 4.3:

sudo update-alternatives --config gcc

libboost-program-options-dev was needed on Ubuntu 8.04 to use cmake, but it's not needed anymore to build a 1.23-render-pipeline on Ubuntu 9.04-beta (nor Snowglobe 2 on Ubuntu 9.10)
make (package: make)
bzip2 (package: bzip2)

The build process may use the following optional tools:

distcc distributed compiler (useful if you have multiple PCs.)
ccache a fast compiler cache (speed up recompilation, a must if you intend to do development.)
Development Environment for Multiple Viewers Boost your productivity as developer; directory structure, multiple viewers, automation of repetitive tasks.

Getting the source

Releases and release candidates are available as source archives (zip or tar) from Source downloads, or you can get the latest (experimental) sources with Subversion.

Using a source archive is safer and strongly recommended for first-time builders. However, if you plan to do active development and want to make your own modifications, while merging Linden Lab's changes, or if you want to live on the bleeding edge, then Subversion should be your choice.

Using the source archives

Get the source from Source downloads. The source is extracted into a directory called linden.

For example,

% tar xzf snowglobe-src-viewer-<version>.tar.gz

Using subversion

Select a source branch to check out.

Check it out with:

% svn checkout http://svn.secondlife.com/svn/linden/<branch> target-directory

If you don't specify the directory, it'll use the last part of the branch path by default.

Installing the required libraries (that Linden Lab can not or does not provide)

Libraries and header files that usually come with a Linux distribution

Make sure the libraries and header files for the following packages are installed on your system:

Library	Debian/Ubuntu	Fedora/Red Hat
libc.so	libc6-dev	glibc-devel
libstdc++.so.6	libstdc++6	libstdc++-devel
libX11.so	libx11-dev	libX11-devel
libGL.so	nvidia-glx-dev or libgl1-mesa-dev	mesa-libGL-devel
libXrender.so	libxrender-dev	libXrender-devel

shortcut commands for the above

Debian/Ubuntu:

sudo apt-get install libc6-dev libstdc++6 libx11-dev libxrender-dev [libgl1-mesa-dev|nvidia-current-dev|...]

Fedora/Red Hat:

sudo yum install glibc-devel libstdc++-devel libX11-devel mesa-libGL-devel libXrender-devel

Recommended libraries and headers

Not really required but you should probably install them. FIX ME: REALLY? WHY?

Library	Debian/Ubuntu	Fedora/Red Hat
libGLU.so	libglu1-mesa-dev	mesa-libGLU-devel
libz.so	zlib1g-dev	zlib-devel
libssl.so	libssl-dev	openssl-devel
libogg.so	libogg-dev	libogg-devel
libpng12.so	libpng12-dev	libpng-devel
libdbus-glib-1.so	libdbus-glib-1-dev	dbus-glib-devel
libatk-1.0.so libcairo.so libgdk-x11-2.0.so libgdk_pixbuf-2.0.so libgmodule-2.0.so libglib-2.0.so libgtk-x11-2.0.so libgthread-2.0.so libpango-1.0.so and many more	libgtk2.0-dev	atk-devel cairo-devel gtk2-devel glib2-devel pango-devel

shortcut commands for the above (2)

Debian/Ubuntu:

sudo apt-get install libglu1-mesa-dev zlib1g-dev libssl-dev libogg-dev libpng12-dev libdbus-glib-1-dev libgtk2.0-dev

Fedora/Red Hat:

sudo yum install mesa-libGLU-devel zlib-devel openssl-devel libogg-devel libpng-devel dbus-glib-devel \
  atk-devel cairo-devel gtk2-devel glib2-devel pango-devel

Installing the Non-Free Shared Libraries and the Artwork Packages

Tip: With Snowglobe, and as of Viewer 2.0, this step can be performed by running:

% scripts/public_fetch_tarballs.py

Some of the artwork and libraries used by the viewer are provided by Linden Lab as two tarballs. You can get these files from the Source downloads page, and unpack them manually over the source tree. You can also find URLs for the specific version of these files needed by your source version in doc/asset_urls.txt.

slviewer-linux-libs-<version>.tar.gz

This file is optional. It contains non-free fonts and the KDU shared library. Obviously, you can also skip it if you are building standalone.

If you download the libs to the top folder, where the linden folder is after getting and extracting the viewer source code tarball, the following command should unpack everything to the right spot:

% tar xvfz slviewer-linux-libs-<version>.tar.gz

slviewer-artwork-<version>.zip

This file contains artwork and various assets and is required in order to run the viewer, or build a package target. It needs to be unzipped over the source tree:

% unzip slviewer-artwork-oss-viewer-<version>.zip

Compiling

This page describes how to build the Second Life viewer with CMake. CMake is a system for generating per-platform build files. On Linux, it will generate your choice of Makefiles or KDevelop project files.

Configuring your tree

Before you first run a build, you'll need to configure things. There's a develop.py script that will create a reasonably sane default configuration for you.

From the command line, cd into the indra subdirectory,

% cd indra

Next you can configure the project by running,

% ./develop.py [-m64|-m32] [--standalone] [--type=Debug] configure [-D...]

Note that -m32 is the default even on 64bit. In order to build for 64-bit you must specify -m64 --standalone. Any cmake defines (starting with -D, see the notes directly below) must be specified after (to the right of) the 'configure' keyword.

Note: To build for 'standalone' (see `What does 'standalone' mean?` above) add --standalone to the configure commandline.

Note: If you want to use KDevelop add -G KDevelop3 to the configure commandline.

Note: Configuring a "non-standalone" version of the source code tree will cause the required (32-bit) third party library packages (as built by Linden Lab) to be downloaded during the CMake build process.

Note: The environment variables CC and CXX are picked up automatically as usual. However, this is not the case of CXXFLAGS and LDFLAGS. If you are compiling Snowglobe then you can pass the following to the configure commandline: -DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" -DCMAKE_EXE_LINKER_FLAGS:STRING="$LDFLAGS" to enable the use of these environment variables.

Note: You can make the build process more verbose (make it print the compiler commands it executes) by passing -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON as well.

Note: For debugging purposes you can build without optimization and with debugging symbols by specifying --type=Debug.

Note: As of version 2.0, passing -DLL_TESTS:BOOL=FALSE will stop running any tests (if any; depends on standalone and viewer version).

If you want to redo this step, erase the CMakeCache.txt file in the build directory and rerun develop.py.

Starting the build

To start a build, do one of the following:

Use the same command that you used to configure (but minus the -D... options), but replace 'configure' with 'build'.

For example: ./develop.py -m64 --standalone --type=Debug build

-- or --

Find your build directory and change to it
In the CMake world, we keep source and object files separate. The develop.py script will create and populate a build directory for you. On Linux, this will be named viewer-linux-ARCH-BUILD (where "ARCH" is "i686" or "x86_64", and "BUILD" varies on debug level)
Build with your preferred build tool
1. Type make
  -- or---
2. Load it into KDevelop

Where's the built viewer?

On Linux, your build will be here:

viewer-linux-ARCH-BUILD/newview/packaged

...where "ARCH" is something like "i686" or "x86_64" (depending on your platform), and "BUILD" depends on which debug level you chose.

Using ccache

It is very highly recommended that you use and install ccache even before the first compile; it will speed up subsequent compiles with a factor of 10 in case you need to redo the compile!

The easiest way to start using ccache is to make symbolic links to ccache from /usr/local/bin. Make sure that /usr/local/bin comes first in your PATH, before the real g++. Thus, as root and assuming you are using gcc/g++ (don't do this if you are using distcc, see below),

% apt-get install ccache
% cd /usr/local/bin
% ln -s ../../bin/ccache gcc
% ln -s ../../bin/ccache g++

And then to test, as normal user (make sure you are not in /usr/local/bin anymore),

% which g++

This should print /usr/local/bin/g++, if not fix you PATH.

Note that by default ccache puts the cache in $HOME/.ccache and will grow till about 1 GB, so make sure you have that diskspace there. Alternatively you can set the environment variable CCACHE_DIR to change the location of the cache.

Using distcc

If you have multiple PCs, you can speed up the build process by using distcc. You probably should still use ccache which has to be run before distcc, therefore both have to be specified in the CXX environment variable, by adding ccache to them.

To use distcc, you need to pass an environment variable CXX containing the distcc command prefix to develop.py when configuring, e.g.,

CXX="ccache distcc g++" ./develop.py configure

Or, if you are using a heterogeneous rows of PCs, you need to add a config prefix to g++, e.g. (in my case, as a Fedora user),

CXX="ccache distcc i386-redhat-linux-g++" ./develop.py configure

Once you did so, the generated makefiles contain instructions to use distcc. You don't need to specify anything special when invoking develop.py to build. The number of concurrent jobs (i.e., -j option to make command) to run is automatically determined by develop.py.

If you invoke make command by yourself, don't forget to add the -j option with an appropriate number.

What to do if it doesn't work for you

Ask for help on IRC (irc.freenode.net #opensl)
Find someone on the opensource-dev mailing list
Fix it: Modifying CMake Files‎ (and please, submit a patch!)

Submitting Patches

This is probably far down the road, but if you make changes to the source and want to submit them, see the page about submitting patches.

User:Opensource Obscure/Compiling the viewer (Linux)

Contents