User:Opensource Obscure/Compiling the viewer (Linux)
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.
See also Version control repository.
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
Tip: With Snowglobe, and as of Viewer 2.0, this step can be performed by running:
|
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 namedviewer-linux-ARCH-BUILD
(where "ARCH" is "i686" or "x86_64", and "BUILD" varies on debug level)
- In the CMake world, we keep source and object files separate. The
- Build with your preferred build tool
- Type
make
- -- or---
- Load it into KDevelop
- Type
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.