= What's this about? =

We're experimenting with the possibility of switching to [http://www.cmake.org/ CMake] for building the Second Life viewer.

== Why change what we're doing? ==

Our current build system is unsatisfactory in several respects.

Within Linden Lab, we use different tools on each platform: [http://www.scons.org/ scons] on Linux, Visual Studio 2003 on Windows, and XCode on OS X.
* Any time we add or rename a source file, updating the various build instructions is painful.
* We can't easily stay up to date with newer tools, such as Visual Studio 2005 or 2008.
* Merging changes to the project files used by XCode and Visual Studio is a nightmare.

== What does CMake buy us? ==

CMake has the advantage of generating per-platform build files for us. On Linux, it will generate Makefiles and KDevelop project files. On OS X, it will generate Makefiles and XCode project files. On Windows, it will generate Makefiles (for nmake) and Visual Studio project files.

All of the "smarts" stay in the CMake files, so there's just one authoritative source of build knowledge. This means that people can use the development environment they prefer without having to worry so much about breaking other people's builds. Because CMake files are plain text, merging is easy, as is maintaining experimental patches.

CMake instructs your build system in how to rebuild its input files when it detects changes to CMake's configuration files. This means that you only need to run <code>cmake</code> once. After that, <code>make</code> or your IDE should keep the CMake files and its own project files in sync for you.

== What are some downsides to CMake? ==

Please note: none of the following caveats is really serious.

The CMake configuration language is weird and ugly.

The tool has some peculiar inconsistencies: some variables and actions are inherited across files, and others are not. There's no regularity to these, so you have to bump into them one by one.

The documentation is weak. It's mostly organised as reference documentation that assumes that you already know how to use CMake. This is a much bigger problem for new projects than ones that have already bit the bullet. We've already worked through the early "WTF?" stages. It's much easier to hack on existing CMake files than it is to create new ones from scratch with no prior experience.

= Performing a build with CMake =

First of all, you'll need to [http://www.cmake.org/HTML/Download.html download CMake], and install it. On Linux distros, it's usually available as a native package. On Windows and OS X, just use the prebuilt binaries.

These are Linux/Mac instructions. The Windows instructions are presumably similar, except you wave your mouse around instead of running commands.

Check out a copy of the viewer cmake branch. NOTE: This does not yet exist!
<pre>
svn co http://svn.secondlife.com/svn/linden/branches/cmake
</pre>
Create a build directory:
<pre>
mkdir mybuild
</pre>
Go into your build directory, and run <code>cmake</code> or <code>ccmake</code> in there, pointing it at the parent directory. If you want to generate a makefile for use by [http://www.gnu.org/software/make/ GNU Make], the defaults will work.
<pre>
cmake ..
</pre>
If you're on a Mac and want to use XCode, use this command instead.
<pre>
cmake -G XCode ..
</pre>

This does not run a build. It just generates the makefiles, project files, or whatever that you'll need. After you're done, you'll have a top-level makefile or project file in your build directory. Run <code>make</code> or load it into your IDE, and away you go!

In principle, your build should run to completion. If you run into any problems, please report them. Better yet, if you can fix them and supply patches, we'd be thrilled!

== Prebuilt libraries vs. standalone builds ==

While many users will want to use the prebuilt libraries that we provide, we're also interested in making life as easy as possible for packagers who want to use their platform's native libraries.

If you run <code>ccmake</code>, you should see a <code>STANDALONE</code> option that determines whether the build will use your system's libraries or our prepackaged ones. Flipping this to <code>TRUE</code> should be all you need to do to perform a packager-friendly build.

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

= Patching guidelines =

We welcome your patches! We can't test on every permutation of platform, compiler, IDE, and libraries, so if you have problems that you can fix, please contribute your fixes and we'll do our best to ensure that you only have to fix problems once.

If you're sending patches in, please follow a few simple guidelines:
* Use regular context diffs.
* Follow the existing coding style in the CMake files. I don't like code shouting at me, so prefer lowercase letters.
* One logical change per patch.
* Use spaces for indentation, not tabs.

I'd like to try an experiment with the development process. Instead of creating JIRA issues, please send your patches to <code>bos at lindenlab dot com</code>, and CC <code>sldev</code>. Inline patches are preferred over attachments, unless your email client trashes white space (as many do).

CMake

2007-12-10T23:23:37Z

Sardonyx Linden:

CMake

2007-12-10T23:22:40Z

Sardonyx Linden:

CMake

2007-12-10T23:20:25Z

Sardonyx Linden:

= Building the viewer using CMake =

We're experimenting with the possibility of switching to [http://www.cmake.org/ CMake] for building the Second Life viewer.

== Why change what we're doing?

Our current build system is unsatisfactory in several respects.

Within Linden Lab, we use different tools on each platform: [http://www.scons.org/ scons] on Linux, Visual Studio 2003 on Windows, and XCode on OS X.
* Any time we add or rename a source file, updating the various build instructions is painful.
* We can't easily stay up to date with newer tools, such as Visual Studio 2005 or 2008.
* Merging changes to the project files used by XCode and Visual Studio is a nightmare.

== What does CMake buy us? ==

CMake has the advantage of generating per-platform build files for us. On Linux, it will generate Makefiles and KDevelop project files. On OS X, it will generate Makefiles and XCode project files. On Windows, it will generate Makefiles (for nmake) and Visual Studio project files.

All of the "smarts" stay in the CMake files, so there's just one authoritative source of build knowledge. This means that people can use the development environment they prefer without having to worry so much about breaking other people's builds. Because CMake files are plain text, merging is easy, as is maintaining experimental patches.

CMake instructs your build system in how to rebuild its input files when it detects changes to CMake's configuration files. This means that you only need to run <code>cmake</code> once. After that, <code>make</code> or your IDE should keep the CMake files and its own project files in sync for you.

== What are the disadvantages of CMake? ==

The CMake configuration language is weird and ugly.

The documentation is poor. This is a much bigger problem for new projects than ones that already have CMake in place. We've already survived the early "WTF?" stages; it's much easier to hack on existing CMake files than it is to create new ones from scratch.

= Performing a build with CMake =

First of all, you'll need to [http://www.cmake.org/HTML/Download.html download CMake], and install it. On Linux distros, it's usually available as a native package. On Windows and OS X, just use the prebuilt binaries.

These are Linux/Mac instructions. The Windows instructions are presumably similar, except you wave your mouse around instead of running commands.

Check out a copy of the viewer cmake branch:
<pre>
svn co http://svn.secondlife.com/svn/linden/branches/cmake
</pre>
Create a build directory:
<pre>
mkdir mybuild
</pre>
Go into your build directory, and run <code>cmake</code> or <code>ccmake</code> in there, pointing it at the parent directory. If you want to generate a makefile for use by [http://www.gnu.org/software/make/ GNU Make], the defaults will work.
<pre>
cmake ..
</pre>
If you're on a Mac and want to use XCode, use this command instead.
<pre>
cmake -G XCode ..
</pre>

This does not run a build. It just generates the makefiles, project files, or whatever that you'll need. After you're done, you'll have a top-level makefile or project file in your build directory. Run <code>make</code> or load it into your IDE, and away you go!

In principle, your build should run to completion. If you run into any problems, please report them. Better yet, if you can fix them and supply patches, we'd be thrilled!

== Prebuilt libraries vs. standalone builds ==

While many users will want to use the prebuilt libraries that we provide, we're also interested in making life as easy as possible for packagers who want to use their platform's native libraries.

If you run <code>ccmake</code>, you should see a <code>STANDALONE</code> option that determines whether the build will use your system's libraries or our prepackaged ones. Flipping this to <code>TRUE</code> should be all you need to do to perform a packager-friendly build.

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

== Patching guidelines ==

If you're sending patches in, please follow a few simple guidelines:
* Use regular context diffs.
* Follow the existing coding style in the CMake files. I don't like code shouting at me, so prefer lowercase letters.
* One logical change per patch.
* Use spaces for indentation, not tabs.

I'd like to try an experiment with the development process. Instead of creating JIRA issues, please send your patches to <code>bos at lindenlab dot com</code>, and CC <code>sldev</code>. Inline patches are preferred over attachments, unless your email client trashes white space (as many do).

CMake

2007-12-10T23:02:16Z

Sardonyx Linden:

CMake

2007-12-10T22:58:51Z

Sardonyx Linden:

CMake

2007-12-10T22:57:12Z

Sardonyx Linden:

2007-05-30T19:09:21Z

Sardonyx Linden: Add notes for building on Fedora

{{CompileNav}}

The following are instructions for building the Second Life viewer on linux. This process has been used on [http://www.debian.org/ debian] and debian based systems like [http://www.ubuntu.com/ ubuntu], and also on [http://www.fedoraproject.org/ Fedora]. For other platforms, see [[Get source and compile]].

== Installing the required dependencies ==

The Second Life Viewer has a number of compile/link dependencies on external libraries which need to be put in place first - 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). The Second Life Viewer is not a trivial build, and experience with building large software packages will help you greatly - but don't be daunted, it should be simple once the dependencies are in the right place the first time.

Paths and package names given here are based on Ubuntu 6.06 and may vary according to your Linux distribution.

*If you download the art and libs to the top folder, where the linden folder is after getting the veiwer source code, the following commands should unpack everything to the right spot.

<code>
unzip slviewer-artwork-<version>.zip
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>

=== Prerequisites ===
{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

* You will need the SCons build tool [package: scons]
* You should use the GCC 3.4 C/C++ compiler [debian/ubuntu: g++-3.4, fedora: compat-gcc-34-c++]; other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without some code adjustments.

* fetch and unpack FMOD 3.75 <http://www.fmod.org/>
** FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. If you wish to avoid FMOD, thus disabling audio, you may make these changes:
*** Remove the reference to 'fmod-3.75' in indra/SConstruct
*** Replace '-DLL_SDL=1' with '-DLL_SDL=1 -DLL_FMOD=0' in indra/SConstruct
*** Comment-out the libfmod line in indra/newview/viewer_manifest.py

**If you want to use FMOD:
<code>
wget http://www.fmod.org/files/fmodapi375linux.tar.gz
tar -xzvf fmodapi375linux.tar.gz
cd fmodapi375linux/
cp api/inc/* ../linden/libraries/i686-linux/include/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>

* You will need the Curl library [debian/ubuntu: libcurl-dev, fedora: curl-devel] - at least version 7.15.4 is recommended, 7.16.x is ideal.
** If you are compiling your own version of Curl, then you should consider configuring it to use the c-ares library so that DNS lookups will be asynchronous.

* You will need some development headers for OpenGL and X11: gl.h, glext.h, glu.h, Xlib.h, and Xutil.h [debian/ubuntu: mesa-common-dev, libglu1-mesa-dev, libx11-dev, fedora: mesa-libGL-devel, mesa-libGLU-devel, libX11-devel]

* You will need GTK 2.x development headers [debian/ubuntu: libgtk2.0-dev, fedora: gtk2-devel]

* You will need yacc and lex [suggest packages: bison, flex]

* You may either use our easy slviewer-linux-libs bundle of pre-built libraries and headers unpacked into the Second Life Viewer source tree, or (for example if you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries) you will have to install the following additional dependencies:
** boost [debian/ubuntu: libboost-dev, fedora: boost-devel]
** boost-regex [debian/ubuntu: libboost-regex-dev]
** apr-1 [debian/ubuntu: libapr1.0-dev, fedora: apr-devel]
** aprutil-1 [debian/ubuntu: libaprutil1.0-dev, fedora: apr-util-devel]
** xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
*** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
*** Apply patches from the instructions in [[patch xmlrpc-epi]].
** jpeglib [debian/ubuntu: libjpeg62-dev, fedora: libjpeg-devel]
** SDL [libsdl1.2-dev, fedora: SDL-devel]
** Google perftools 0.91 or greater [debian/ubuntu: google-perftools-dev, fedora: google-perftools-devel]
** Vorbis [debian/ubuntu: libvorbis-dev, fedora: libvorbis-devel]
** build ELFIO <http://sourceforge.net/projects/elfio/>
*** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so: <code>cd ELFIO && g++-3.4 -shared *.o -o libelfio.so</code>
** build OpenJPEG <http://www.openjpeg.org/>
*** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
*** 02-26-2007, another set of patches is required to Second Life to make it usable, that is fix a crash, make it look good, and speed it up. See https://jira.secondlife.com:443/browse/VWR-123
** expat [debian/ubuntu: libexpat1-dev, fedora: expat-devel]

=== Copy headers and libraries into the source tree ===

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.
* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
* ${FMOD} refers to the top-level directory into which you unpacked FMOD 3.
<code>
cp ${FMOD}/api/inc/* ${SLSRC}/libraries/i686-linux/include/
cp ${FMOD}/api/libfmod-3.75.so ${SLSRC}/libraries/i686-linux/lib_release_client/
</code>
You only need to copy the following if you're not using the handy slviewer-linux-libs package:
<code>
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include/

</code>

=== Fix Shell Scripts ===

''This has been fixed in [http://blog.secondlife.com/2007/05/04/preview-of-second-life-116-on-the-beta-test-grid-sculpties/ 1.16.0]. Looks it was fixed in 1.15.0.2 too''--[[User:Signore Iredell|Signore Iredell]] 14:56, 6 May 2007 (PDT)

Some systems don't use bash for /bin/sh. Ubuntu is one example. If this is the case on your system, you must do the following, since these scripts are actually bash scripts, but call /bin/sh.

Edit the first line of these scripts, changing ''#!/bin/sh'' to ''#!/bin/bash''
* linden/indra/newview/linux_tools/launch_url.sh
* linden/indra/newview/linux_tools/wrapper.sh
* linden/libraries/include/boost/pool/detail/pool_construct_simple.sh
* linden/libraries/include/boost/pool/detail/pool_construct.sh
* linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h
** ''(it's at line 47 - 1.15.0.2 release)''

=== Disable llMozLib ===

Add MOZLIB=no to your Scons build command when compiling the source.

=== Libs ===

If you are using our easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.
<code>
cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

mkdir ${SLSRC}/libraries/i686-linux/include/expat
cp -a /usr/include/expat*.h ${SLSRC}/libraries/i686-linux/include/expat/

mkdir ${SLSRC}/libraries/i686-linux/include/zlib
cp -a /usr/include/zlib*.h ${SLSRC}/libraries/i686-linux/include/zlib/

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>

== Compiling ==

<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.

== 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. 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:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
</code>

* Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin )
</code>

** For version '''20070117a''' the binary name seems to have changed to '''secondlife-i686-bin-globalsyms''', so the command would be (Tofu Linden says - this was an oversight after a build process change, and future releases will generate a '''secondlife-i686''' again, whereupon this instruction can be removed. :))
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin-globalsyms )
</code>

==== Augh!! The client seems REALLY 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. Unfortunately 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 smoother 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 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:
<code>
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"
</code>

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.

==== "Unable to initialize communications" ====

If the viewer just displays the error message " Unable to initialize communications" and exits, it can't find message_template.msg. You did remember to copy it over, right?

=== 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

==== Packaging errors ====

The final packaging step may fail with errors about the manifest if you are not using the slviewer-linux-libs bundle; in this case, if you still wish to end up with an end-user viewer package incorporating your own libraries, you can edit the manifest file found at indra/newview/viewer_manifest.py

==== Automated libraries and headers adjustments, compilation and packaging ====

Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.00 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro.

# Where the sources of the client will be held (defaults to "linden"):
PATH_TO_SOURCES="/usr/src/SL"
# Where to build the client:
export TEMP_BUILD_DIR="$HOME/secondlife"

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
USE_SYSTEM_DB4="yes"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_APR="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="yes"
USE_SYSTEM_EXPAT="yes"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
USE_SYSTEM_FREETYPE2="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp -mtune=athlon-xp"
TUNE_FLAGS=""

# Whether to build with the browser login screen or not:
WITH_MOZILLA="no"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

# Check to see if we simply want to retry a compilation:
if [ "$1" == "--retry" ] ; then
compile
exit $?
fi

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

# Let's use the system expat if available:
if [ -f /usr/include/expat.h ] && [ "$USE_SYSTEM_EXPAT" == "yes" ] ; then
echo "Using the system expat..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/expat/
rm -f i686-linux/lib_release_client/libexpat*
mkdir -p i686-linux/include/expat
cp -a /usr/include/expat*.h i686-linux/include/expat/
update_manifest libexpat
fi

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# / /" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-O2/-O2 $TUNE_FLAGS/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

compile
</nowiki>
</pre>
</code>

== FreeBSD ==

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

Build the Viewer on Linux

2007-05-25T16:50:14Z

Sardonyx Linden: Mention Google perftools

{{CompileNav}}

The following are instructions for building the Second Life viewer on linux. This process has only been used on [http://www.debian.org/ debian] and debian based systems like [http://www.ubuntu.com/ ubuntu]. For other platforms, see [[Get source and compile]].

== Installing the required dependencies ==

The Second Life Viewer has a number of compile/link dependencies on external libraries which need to be put in place first - 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). The Second Life Viewer is not a trivial build, and experience with building large software packages will help you greatly - but don't be daunted, it should be simple once the dependencies are in the right place the first time.

Paths and package names given here are based on Ubuntu 6.06 and may vary according to your Linux distribution.

*If you download the art and libs to the top folder, where the linden folder is after getting the veiwer source code, the following commands should unpack everything to the right spot.

<code>
unzip slviewer-artwork-<version>.zip
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>

=== Prerequisites ===
{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

* You will need the SCons build tool [package: scons]
* You should use the GCC 3.4 C/C++ compiler [package: g++-3.4]; other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without some code adjustments.

* fetch and unpack FMOD 3.75 <http://www.fmod.org/>
** FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. If you wish to avoid FMOD, thus disabling audio, you may make these changes:
*** Remove the reference to 'fmod-3.75' in indra/SConstruct
*** Replace '-DLL_SDL=1' with '-DLL_SDL=1 -DLL_FMOD=0' in indra/SConstruct
*** Comment-out the libfmod line in indra/newview/viewer_manifest.py

**If you want to use FMOD:
<code>
wget http://www.fmod.org/files/fmodapi375linux.tar.gz
tar -xzvf fmodapi375linux.tar.gz
cd fmodapi375linux/
cp api/inc/* ../linden/libraries/i686-linux/include/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>

* You will need the Curl library [package: libcurl-dev] - at least version 7.15.4 is recommended, 7.16.x is ideal.
** If you are compiling your own version of Curl, then you should consider configuring it to use the c-ares library so that DNS lookups will be asynchronous.

* You will need some development headers for OpenGL and X11: gl.h, glext.h, glu.h, Xlib.h, and Xutil.h [packages: mesa-common-dev, libglu1-mesa-dev, libx11-dev]

* You will need GTK 2.x development headers [libgtk2.0-dev]

* You will need yacc and lex [suggest packages: bison, flex]

* You may either use our easy slviewer-linux-libs bundle of pre-built libraries and headers unpacked into the Second Life Viewer source tree, or (for example if you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries) you will have to install the following additional dependencies:
** boost [libboost-dev]
** boost-regex [libboost-regex-dev]
** apr-1 [libapr1.0-dev]
** aprutil-1 [libaprutil1.0-dev]
** xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
*** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
*** Apply patches from the instructions in [[patch xmlrpc-epi]].
** jpeglib [libjpeg62-dev]
** SDL [libsdl1.2-dev]
** Google perftools 0.91 or greater [google-perftools-dev]
** Vorbis [libvorbis-dev]
** build ELFIO <http://sourceforge.net/projects/elfio/>
*** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so: <code>cd ELFIO && g++-3.4 -shared *.o -o libelfio.so</code>
** build OpenJPEG <http://www.openjpeg.org/>
*** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
*** 02-26-2007, another set of patches is required to Second Life to make it usable, that is fix a crash, make it look good, and speed it up. See https://jira.secondlife.com:443/browse/VWR-123
** expat [libexpat1-dev]

=== Copy headers and libraries into the source tree ===

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.
* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
* ${FMOD} refers to the top-level directory into which you unpacked FMOD 3.
<code>
cp ${FMOD}/api/inc/* ${SLSRC}/libraries/i686-linux/include/
cp ${FMOD}/api/libfmod-3.75.so ${SLSRC}/libraries/i686-linux/lib_release_client/
</code>
You only need to copy the following if you're not using the handy slviewer-linux-libs package:
<code>
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include/

</code>

=== Fix Shell Scripts ===

''This has been fixed in [http://blog.secondlife.com/2007/05/04/preview-of-second-life-116-on-the-beta-test-grid-sculpties/ 1.16.0]. Looks it was fixed in 1.15.0.2 too''--[[User:Signore Iredell|Signore Iredell]] 14:56, 6 May 2007 (PDT)

Some systems don't use bash for /bin/sh. Ubuntu is one example. If this is the case on your system, you must do the following, since these scripts are actually bash scripts, but call /bin/sh.

Edit the first line of these scripts, changing ''#!/bin/sh'' to ''#!/bin/bash''
* linden/indra/newview/linux_tools/launch_url.sh
* linden/indra/newview/linux_tools/wrapper.sh
* linden/libraries/include/boost/pool/detail/pool_construct_simple.sh
* linden/libraries/include/boost/pool/detail/pool_construct.sh
* linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h
** ''(it's at line 47 - 1.15.0.2 release)''

=== Disable llMozLib ===

Add MOZLIB=no to your Scons build command when compiling the source.

=== Libs ===

If you are using our easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.
<code>
cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

mkdir ${SLSRC}/libraries/i686-linux/include/expat
cp -a /usr/include/expat*.h ${SLSRC}/libraries/i686-linux/include/expat/

mkdir ${SLSRC}/libraries/i686-linux/include/zlib
cp -a /usr/include/zlib*.h ${SLSRC}/libraries/i686-linux/include/zlib/

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>

== Compiling ==

<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.

== 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. 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:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
</code>

* Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin )
</code>

** For version '''20070117a''' the binary name seems to have changed to '''secondlife-i686-bin-globalsyms''', so the command would be (Tofu Linden says - this was an oversight after a build process change, and future releases will generate a '''secondlife-i686''' again, whereupon this instruction can be removed. :))
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin-globalsyms )
</code>

==== Augh!! The client seems REALLY 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. Unfortunately 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 smoother 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 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:
<code>
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"
</code>

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.

==== "Unable to initialize communications" ====

If the viewer just displays the error message " Unable to initialize communications" and exits, it can't find message_template.msg. You did remember to copy it over, right?

=== 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

==== Packaging errors ====

The final packaging step may fail with errors about the manifest if you are not using the slviewer-linux-libs bundle; in this case, if you still wish to end up with an end-user viewer package incorporating your own libraries, you can edit the manifest file found at indra/newview/viewer_manifest.py

==== Automated libraries and headers adjustments, compilation and packaging ====

Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.00 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro.

# Where the sources of the client will be held (defaults to "linden"):
PATH_TO_SOURCES="/usr/src/SL"
# Where to build the client:
export TEMP_BUILD_DIR="$HOME/secondlife"

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
USE_SYSTEM_DB4="yes"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_APR="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="yes"
USE_SYSTEM_EXPAT="yes"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
USE_SYSTEM_FREETYPE2="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp -mtune=athlon-xp"
TUNE_FLAGS=""

# Whether to build with the browser login screen or not:
WITH_MOZILLA="no"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

# Check to see if we simply want to retry a compilation:
if [ "$1" == "--retry" ] ; then
compile
exit $?
fi

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

# Let's use the system expat if available:
if [ -f /usr/include/expat.h ] && [ "$USE_SYSTEM_EXPAT" == "yes" ] ; then
echo "Using the system expat..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/expat/
rm -f i686-linux/lib_release_client/libexpat*
mkdir -p i686-linux/include/expat
cp -a /usr/include/expat*.h i686-linux/include/expat/
update_manifest libexpat
fi

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# / /" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-O2/-O2 $TUNE_FLAGS/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

compile
</nowiki>
</pre>
</code>

== FreeBSD ==

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