Build the Viewer on Linux

From Second Life Wiki
Revision as of 06:31, 1 January 2009 by Alissa Sabre (talk | contribs) (Made some changes, as my feedback. Yes, I believe some people dislikes my changes. Please feel free to find compromises and rewrite them!)
Jump to navigation Jump to search
Open Source Portal

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.

  • python 2.4 [package: python]
    • python 2.3 or before doesn't work in SL development.
    • python 2.5 or later works, but it is not recommended, since it generates a lot of warning messages when running develop.py.
  • GCC 4.1 or later C++ compiler.
    • In a past, GCC 3.4 C/C++ compiler [debian/ubuntu: g++-3.4] [fedora: compat-gcc-34-c++] was recommended for SL development, but recent SL viewer requires gcc 4 series.
      • libboost-program-options-dev is needed on Ubuntu 8.04 to use cmake
  • yacc or compatible tool [suggest packages: bison]
  • lex or compatible tool [suggest packages: flex]

The build process may use the following optional tool:

  • distcc distributed compiler (useful if you have multiple PCs.)

Unpack the source tree

You can get the source either from the source archives available at Source downloads, or you can get it from Subversion.

Using a source archive is the easier option for getting started, and is strongly recommended especially for the first-time builders. However, some says that if you plan to do active development and want to make your own modifications, while merging Linden Lab's changes, Subversion will probably be much more convenient on the long term.

Getting the source from the source archives

Get the source from Source downloads. You will need all 3 archives: source, artwork and libraries.

Choose a location and unpack the source tree and the art work. They will be extracted into a directory called linden. 

% tar -xzf slviewer-src-<version>.tar.gz
% tar -xzf slviewer-linux-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip

Getting the source from Subversion

Select a source branch to check out.

Check it out with: 

% svn co http://svn.secondlife.com/svn/linden/<branch> [directory]

If you don't specify the directory, it'll use the name of the branch as the default.

Now you will have a directory with the source code. This only includes the source code itself, without the libraries or artwork. You will have to get them from the Source downloads and unpack them into the tree.

If the directory SVN created is called 'linden' then you can directly unzip and untar the archives on top of it. If it's called something else, create a symlink: 

% ln -sf <branch> linden

Now unpack the libraries and artwork: 

% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip


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:

GL
[ubuntu: mesa-common-dev, fedora: mesa-libGL-devel]
GLU
[ubuntu: libglu1-mesa-dev, fedora: mesa-libGLU-devel]
glibc
[ubuntu: libc6-dev, fedora: glibc-devel]
stdc++ library
[ubuntu: libstdc++6, fedora: libstdc++-devel]
X11
[ubuntu: libx11-dev, fedora: libX11-devel]
zlib
[ubuntu: zlib1g-dev, fedora: zlib-devel]
openssl
[ubuntu: libssl-dev, redhat: openssl-devel]

FMOD (audio)

FMOD is an audio output library. FMOD is required to make SL viewer to generates sounds. 

wget http://www.fmod.org/index.php/release/version/fmodapi375linux.tar.gz
tar -xzvf fmodapi375linux.tar.gz
mkdir -p linden/libraries/i686-linux/lib_release_client/
mkdir -p linden/libraries/i686-linux/lib_debug/
mkdir -p linden/libraries/i686-linux/lib_release/
cd fmodapi375linux/
cp api/inc/* ../linden/libraries/i686-linux/include/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_debug/
  • FMOD is available free of charge, but it is not itself an open-source. We understand that some Linux users dislike to use software whose source is not open, and FMOD falls into this category. If you wish to avoid FMOD, thus disabling audio, you may make these changes:
    • Comment-out the libfmod line in indra/newview/viewer_manifest.py

Installing the required dependencies (prepackaged by Linden Lab)

The Second Life Viewer has a number of compile/link dependencies on external libraries which are needed - to help you, the source download page contains a link to a slviewer-linux-libs package which you unpack over the source tree to fill most of the dependencies (and thus avoid most of the fiddly work described on this page).

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

Note: as of 1.21, very little of what once was included in the libraries tarball are still there, so this is a very small tarball. The other libraries will be downloaded as part of the build process.

If you don't wish to use the precompiled libraries, see Building the viewer libraries (Linux).

Compiling

For viewers 1.21 and beyond, see Building the viewer with CMake

For older viewers (1.20 and earlier) see Compiling the viewer with SCons (Linux)

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:

FreeBSD

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

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.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Build_the_Viewer_on_Linux&oldid=190162"