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.

What does 'Standalone' mean?

A standalone build of the viewer refers to building a viewer against the shared libraries that are installed on your system instead of using precompiled libraries provided by Linden Lab.

In order to build standalone, you will have to configure using --standalone, see configuration below.

The advantage of building standalone is that you might use less RAM: you'll be using the same shared libraries that other applications use. However this is a rather minor advantage. The disadvantages of building standalone is a long list of potential problems: you will have to manually install all the development packages of many many libraries. In some cases there isn't a package for it from your distribution, so you have to especially get those sources separately and compile and install them in a way that the viewer can find them. Building standalone is not supported officially by Linden Lab and therefore not tested. Hence, it might not work at all (although the open source snowglobe developers usually make sure that it works for snowglobe). Nevertheless, every now and then it happens that the viewer won't build with some new released library (ie, boost), in which case you most likely will have to use the latest source code retrieved with subversion.

Nevertheless, there might be reasons that you want to do a standalone build anyway. The most important one being that Linden Lab also doesn't support 64-bit: they do not provided shared libraries for 64-bit; so, if you want to build native 64 bit you must use standalone. Another reason might be that Linden Lab is using a few rather old library versions that are incompatible with newer versions. If you have any reason to use a newer version for some library, then chances are that things will break unless you build standalone. One reason would be if you want to debug a library and fix it because it is buggy.

Conclusion: if you are building the viewer for the first time, and you are building for 32-bit, then you should not use standalone.

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)

Even non-standalone still uses a few shared libraries from your system. This paragraph deals with those libraries. For standalone you will need a lot more (see later on).

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

The following packages are required when building standalone, but even if you are building non-standalone you should probably install them.

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

Necessary libraries when building standalone

Existing package names

If you want to build 'standalone', then the following packages are required in addition:

Library	Debian/Ubuntu	Fedora/Red Hat
libopenal.so	libopenal-dev	openal-soft-devel
libvorbis.so libvorbisenc.so libvorbisfile.so	libvorbis-dev	libvorbis-devel
libalut.so	libalut-dev	freealut-devel
libapr-1.so	libapr1-dev	apr-devel
libaprutil-1.so	libaprutil1-dev	apr-util-devel
libboost_program_options.so libboost_regex.so libboost_signals.so	libboost-dev	boost-devel
libcares.so	libc-ares-dev	c-ares-devel
libxmlrpc-epi.so	libxmlrpc-epi-dev	?
libopenjpeg.so	libopenjpeg-dev	openjpeg-devel
libjpeg.so	libjpeg62-dev (libjpeg-dev)	libjpeg-devel
libSDL.so	libsdl1.2-dev	SDL-devel
libgstreamer-0.10.so	libgstreamer0.10-dev	gstreamer-devel
gstreamer-0.10 plugins	libgstreamer-plugins-base0.10-dev	gstreamer-plugins-base-devel
libgmock.so	google-mock (Snowglobe 2 only)	?

shortcut commands for the above (3)

Debian/Ubuntu:

sudo apt-get install libopenal-dev libvorbis-dev libalut-dev libapr1-dev libaprutil1-dev libboost-dev \
  libc-ares-dev libxmlrpc-epi-dev libopenjpeg-dev libjpeg62-dev libgtk2.0-dev libsdl1.2-dev \
  libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev google-mock

Fedora/Red Hat:

sudo yum install openal-soft-devel libvorbis-devel freealut-devel apr-devel apr-util-devel boost-devel \
  c-ares-devel openjpeg-devel libjpeg-devel SDL-devel gstreamer-devel gstreamer-plugins-base-devel

Get voice chat working (standalone)

The voice binaries downloaded for non-standalone builds can be used in for standalone builds, too. Because they'll run as a separate process, this even works with 64-bit builds of the viewer (assuming your system is set up for also running 32-bit binaries). To download and unpack the binaries (which doesn't happen automatically when building standalone) run:

${SOURCE_DIR}/scripts/install.py vivox

After building, you'll have to copy the binaries into the right place (-- I don't think this is correct as this will also link the viewer against those libraries. Instead you have to use a script for SLVoice that sets the right LD_LIBRARY_PATH and then runs the real SLVoice --Aleric Inglewood 12:03, 13 July 2010 (UTC)):

cp ${SOURCE_DIR}/indra/newview/vivox-runtime/i686-linux/SLVoice ${BUILD_DIR}/newview/packaged/bin/
cp ${SOURCE_DIR}/indra/newview/vivox-runtime/i686-linux/*.so* ${BUILD_DIR}/newview/packaged/lib/

If you want, you can then remove the voice binaries again from the source tree with

${SOURCE_DIR}/scripts/install.py --uninstall vivox

Remaining issues (standalone)

In order to run the viewer you need to create a 'package' (a directory really, to which everything is copied that is needed to run it). Unfortunately, if you are building standalone on a 32-bit machine, it still tries to happily copy the Linden Lab provided shared libraries over, which we never even downloaded mind you, causing the packaging to fail. Therefore, edit indra/newview/viewer_manifest.py and comment out the following lines in class Linux_i686Manifest(LinuxManifest):

            #self.path("libapr-1.so.0")
            #self.path("libaprutil-1.so.0")
            #self.path("libdb-4.2.so")
            #self.path("libcrypto.so.0.9.7")
            #self.path("libexpat.so.1")
            #self.path("libssl.so.0.9.7")
            #self.path("libuuid.so.1")
            #self.path("libSDL-1.2.so.0")
            #self.path("libELFIO.so")
            #self.path("libopenjpeg.so.1.3.0", "libopenjpeg.so.1.3")
            #self.path("libalut.so")
            #self.path("libopenal.so", "libopenal.so.1")
            self.end_prefix("lib")

            # Vivox runtimes
            #if self.prefix(src="vivox-runtime/i686-linux", dst="bin"):
            #        self.path("SLVoice")
            #        self.end_prefix()
            #if self.prefix(src="vivox-runtime/i686-linux", dst="lib"):
            #        self.path("libortp.so")
            #        self.path("libvivoxsdk.so")
            #        self.end_prefix("lib")

Also, until VWR-9475 really gets fixed (it was fixed before, but not really), you need to install the 'SDL' precompiled library on standalone in order to get the needed cursor bitmaps (not necessary for Snowglobe 2.x):

% scripts/install.py SDL

However, if you are building standalone on 32-bit, that would also cause the wrong (non-system) headers and library to be included, so you will need to remove those again on 32-bit (from libraries/i686-linux/include/ and libraries/i686-linux/lib_release_client/).

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.

NOTE: These instructions are for the viewers using cmake (versions 1.21 and beyond). For older viewers (1.20 and earlier) see Compiling the viewer with SCons (Linux)

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.

Important:

Everything below is probably outdated. It should be carefully sorted, cleaned up, updated and deleted (added 14/7/2010)

Prebuilt libraries vs. standalone builds

For standalone builds, we'd really like to beef up the checks for system libraries so that for example cmake will fail if a required library (such as OpenJPEG) isn't installed. We welcome all patches that help out with this.

cmake-SL: a script for standalone, pre-built and mixed libraries viewer builds under Linux.
Problems when compiling a standalone Linux viewer

Testing and packaging the client

Testing the result from inside the tree

You may find it simpler and less error-prone to follow the instructions in the Packaging the client section below to run the client under the same conditions as an end-user would.

2008-05-29 (Ochi Wolfe): Compiling the 1.20.7 r88152 viewer, it seems like even when compiling as "release" the viewer is built ready-to-go inside the newview/packaged/ directory including the message_template.msg and message.xml in the right place. Try to cd to the newview/packaged/ directory and run SL from there with the ./secondlife command as you would normally do.

Otherwise:

Preparing to run 'in-tree'
- ensure that you have indra/newview/app_settings/static_*.db2 - if not, you'll find it in the slviewer-artwork download (a zip file).
- now, from the indra directory:

$ cp ../scripts/messages/message_template.msg newview/app_settings/
$ cp ../etc/message.xml newview/app_settings/

Important: Starting from version 1.18.0, copying message.xml is also required. Missing it will cause group IMs to fail to work, although the viewer will run fine otherwise.

Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:

$ ( cd newview && LD_LIBRARY_PATH="`pwd`"/../../libraries/i686-linux/lib_release_client:"`pwd`"/app_settings/mozilla-runtime-linux-i686:${LD_LIBRARY_PATH}:/usr/local/lib  ./secondlife-i686-bin )

The client seems kinda slow.

By default, the open-source Second Life Viewer uses the open-source OpenJPEG library to decode the (many) JPEG-2000 texture images it receives from the servers. This isn't quite of comparable speed to the proprietary third-party library which the Linden Lab viewer builds have traditionally used, for which we are not permitted to redistribute the source.

However, the slviewer-linux-libs package includes two pre-built libraries which facilitate the use of this slightly faster image decoding method: libkdu_v42R.so and libllkdu.so. These are provided for your testing; again, we are not permitted to grant you the right to re-distribute these libraries to downstream users, but the viewer will still work (albeit slightly slower) without them.

To use these faster image-decoding libraries, they simply need to be put into the right places relative to the viewer runtime directory - nothing needs to be reconfigured or recompiled. If you're running the client from the source tree, the following will make the KDU libraries available:

cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
mkdir "$SLSRC/indra/lib"
cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"

The file indra/newview/viewer_manifest.py contains some commented-out entries describing where these libraries belong; if you uncomment the two lines corresponding to libllkdu and libkdu then they will be automatically copied into the right place in the runtime directory when you follow the 'Packaging the client' instructions below.

File Dialogs Don't Work on 64 bit system

If you run a 64 bit system, and your file dialogs don't work, or they worked before and stopped after you installed an update, it may be due to a mismatch between the headers used to compile the viewer and the library it's using. The log will contain something like this:

2007-06-21T01:28:35Z INFO: ll_try_gtk_init: Starting GTK Initialization.
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: GTK Initialized.
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: - Compiled against GTK version 2.10.11
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: - Running against GTK version 2.10.6
2007-06-21T01:28:36Z WARNING: ll_try_gtk_init: - GTK COMPATIBILITY WARNING: Gtk+ version too old (micro mismatch)

What happens here is that your distribution includes 32 bit GTK libraries, but the package only includes the libraries themselves and not the headers. When building, the SL client will build against the headers included with the main 64 bit GTK package. This will work if the 64 bit version of the library is the same or older than the 32 bit one. However, if your 32 bit library is older, then the viewer will detect the mismatch (built with headers for a newer version of GTK than it's using) and turn GTK off.

Possible solutions:

Download the source for the version of the 32 bit GTK libraries your distribution comes with, and build your viewer against those headers.
Upgrade your 32 bit GTK package so that it's the same or newer as the 64 bit one.
Downgrade your 64 bit package (may not be a good idea).

Packaging the client

If you substitute 'BUILD=release' with 'BUILD=releasefordownload' in the 'Compiling' section above, then packaging the resulting code, libraries, data and documentation into a tarball for the end-user will be done automatically as the final stage of the build process; the pristine end-user client distribution has been assembled into the directory indra/newview/SecondLife_i686_1_X_Y_Z/ and has also been tarred into indra/newview/SecondLife_i686_1_X_Y_Z.tar.bz2

The file which controls what (and where) files go into the end-user runtime viewer directory is indra/newview/viewer_manifest.py

Resident contributed instructions

Automated libraries and headers adjustments, compilation and packaging

Here are two scripts (one for v1.20 and older, and one for v1.21 and newer viewers) that basically do all what is described above, and more, and entitle you to compile a SL client very easily:

Please also see the (user contributed) instructions at User:Michelle2_Zenovka/cmake

FreeBSD

A list of patches is given for Compiling the viewer (FreeBSD).

Library	Debian/Ubuntu
libcurl-cares.so	libcurl4-cares-dev
llqtwebkit	libllqtwebkit-dev (Snowglobe 1) or libllqtwebkit2-dev (Snowglobe 2)
JsonCpp	libjsoncpp-dev
libndofdev	libndofdev-dev (optional, needed if you have a Space Navigator joystick)
glh-linear	glh-linear (Snowglobe 2 only)
boost-coroutine	boost-coroutine (Snowglobe 2 only)

Build the Viewer on Linux

Contents

Required tools

What does 'Standalone' mean?

Getting the source

Using the source archives

Using subversion

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

Libraries and header files that usually come with a Linux distribution

shortcut commands for the above

Recommended libraries and headers

shortcut commands for the above (2)

Necessary libraries when building standalone

Existing package names

shortcut commands for the above (3)

More problematic libraries (standalone)

Get voice chat working (standalone)

Remaining issues (standalone)

Installing the Non-Free Shared Libraries and the Artwork Packages

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

slviewer-artwork-<version>.zip

Compiling

Configuring your tree

Starting the build

Where's the built viewer?

Using ccache

Using distcc

What to do if it doesn't work for you

Submitting Patches

Prebuilt libraries vs. standalone builds

Testing and packaging the client

Testing the result from inside the tree

The client seems kinda slow.

File Dialogs Don't Work on 64 bit system

Packaging the client

Resident contributed instructions

Automated libraries and headers adjustments, compilation and packaging

FreeBSD

Navigation menu

Search