Difference between revisions of "Build the Viewer on Linux"

From Second Life Wiki
Jump to navigation Jump to search
m (fixed "Linden Lab")
m (Note out of date third party libraries)
 
(242 intermediate revisions by 25 users not shown)
Line 1: Line 1:
{{KBcaution|custom=Note|
Linden Lab no longer actively maintains Linux viewer third party dependencies. You may run into issues building the viewer on modern distros.}}
{{multi-lang}}
{{multi-lang}}
{{Warning|The viewer source is under a big transition.  The ways to get and compile the viewer source is different in 1.19, 1.20, and 1.21 series.  Some information about compiling are based on viewer source 1.19 series and before, while some others are based on 1.20 series or even on the coming 1.21 series.  The pages will be consistent when 1.21 series are out and stable.  Thank you for your patience.}}
{{OSWikiContribBox}}
{{CompileNav}}
{{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]].
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]].
 
<onlyinclude>
= Building the client =
To build the Second Life Viewer you will first need to install the required tools and libraries.
The following sections outline steps to build the client from source.  To simplify building,
Linden Lab has been nice enough to prepackage some of the libraries and bundled them up in an
additional tar file.
 
And while 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 tasks are:
# Install required tools.
# Unpack source and art trees from Linden Lab.
# Install libraries not shipped by Linden Lab.
# Unpack or install the other required libraries and headers.
# Compile.
<br />
<br />
== Required tools ==
== Required tools ==
There are a number of tools that need to be installed first.
There are a number of tools that need to be installed first.


* <b>python 2.5</b> [package: python]
* '''hg''' [package: mercurial]
* <b>SCons</b> build tool [package: scons]
* '''cmake''' [package: cmake]
* <b>GCC 3.4</b> C/C++ compiler [debian/ubuntu: g++-3.4] [fedora: compat-gcc-34-c++]  
** Currently (snowglobe 1.3.2 and higher) cmake 2.6.2 is the minimum required version.
** Other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer. (Although some say a few simple code adjustments does the job.)
* <b>yacc</b> or compatible tool [suggested package: bison]
** 2008-05-29 (Ochi Wolfe): Compilation of 1.20.7 r88152 with gcc/g++ version 4.2.4 runs just fine on my Gentoo system without tweaks to the code but the following tweaks to the SConstruct file:
* <b>lex</b> or compatible tool [suggested package: flex]
*** Replace "g++-3.4" with "g++" at line 352 to use your standard g++ (4.2.4 in my case)
* <b>python</b> [package: python]
*** If compilation fails with errors from ld complaining about missing "-lboost_signals-gcc34-mt" or similar: Try using your system's '''boost library''' (make sure it's installed) by searching for "boost_" in the SConstruct and removing all occurences of "gcc34-" or "gcc33-" in those strings. For example: 'boost_signals-gcc34-mt' becomes 'boost_signals-mt'.
** python 2.4.3 is the minimum required version.
*** '''libboost-program-options-dev''' is needed on Ubuntu 8.04 to use cmake
** All more recent 2.x versions should work, too. If you encounter problems or deprecation warnings, please [[issue tracker|report]] them.
** On Fedora, you may need to edit line 342 of indra/SConstruct (Branch_1-18-2-Viewer) as
** python 3.x hasn't been tested yet.
**: change gcc_bin = 'g++-3.4' to gcc_bin = 'g++34'
* <b>g++</b> [package: g++]
* <b>yacc</b> or compatible tool [suggest packages: bison]
** 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 <b>GCC 4.3</b> and to run 'export CXX=/usr/bin/g++-4.3' or whatever your binary is before trying to compile.
* <b>lex</b> or compatible tool [suggest packages: flex]
: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
* Linden Lab has backported gcc-4.6.3 to Debian Squeeze; this port and its associated libraries are used when building the official Linux viewer.
:The sources and Debian packages for this backport are available from [[Debian GCC Backport]]
* '''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:


The build process may use the following optional tool:
* <b>distcc</b> distributed compiler (useful if you have multiple PCs.)
* <b>ccache</b> a fast compiler cache (speed up recompilation, a must if you intend to do development.)


* <b>distcc</b> distributed compiler (useful if you have multiple PCs.)
{{KBhint|To boost your productivity as a developer, try the suggestions at [[Development Environment for Multiple Viewers]] about directory structure, multiple viewers and automation of repetitive tasks.}}


== Unpack the source tree ==
</onlyinclude>


You can get the source either from the source archives available at [[Source downloads]], or you can get it from [[Subversion]].
== What does 'Standalone' mean? ==


Using a source archive is the easier option, but if you plan to do active development and want to make your own modifications, while merging LL's changes, subversion will probably be much more convenient on the long term.
''The current sources no longer use the term "standalone"; it has been replaced by "usesystemlibs".''


=== Getting the source from the source archives ===
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.
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
In order to build standalone, you will have to configure using <code>--standalone</code>, see [[#Configuring_your_tree|configuration]] below.
directory call <b>linden</b>.


<code>
The advantage of building standalone is that you might use less RAM: you'll be using the same shared libraries
% tar -xzf slviewer-src-<version>.tar.gz
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.
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>
<br />


=== Getting the source from 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.
Select a source [[Source branches|branch]] to check out.


Check it out with:
Conclusion: if you are building the viewer for the first time, and you are building for 32-bit, then you should ''not'' use standalone.
<code>
% svn co http://svn.secondlife.com/svn/linden/<branch> [directory]
</code>
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.
== Getting the source ==


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:
The source for the official Viewer's 2.x codebase resides in mercurial repositories hosted on http://bitbucket.org/lindenlab (a.k.a. http://bitbucket.org/lindenlab).
<code>
% ln -sf <branch> linden
</code>


Now unpack the libraries and artwork:
{{KBnote|custom=Old Versions|Find instructions on how to obtain the sources for official 1.x codebase as well as [[Snowglobe]] 1.x and 2.x on the [https://wiki.secondlife.com/w/index.php?title{{=}}Compiling_the_viewer_%28Linux%29&oldid{{=}}1126012#Getting_the_source archived version of this section].}}
<code>
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>


<br />
To check out the '''[[viewer-release (source branch)|lindenlab/viewer-release]]''' branch, do
hg clone http://bitbucket.org/lindenlab/viewer-release
This will create a new folder called <code>viewer-release</code> inside your current working directory, containing the source tree. (You can optionally specify a different target directory. See <code>hg help clone</code>.) Other long-lived branches of interest are '''[[viewer-beta (source branch)|lindenlab/viewer-beta]]''' and '''[[viewer-development (source branch)|lindenlab/viewer-development]]'''. Contributions should usually be based on '''viewer-development'''.


== Installing the required libraries (that Linden Lab can not or does not provide)==
== 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 ===
=== 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:
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]
{|border="1" cellpadding="5" cellspacing="0"
; GLU : [ubuntu: libglu1-mesa-dev, fedora: mesa-libGLU-devel]
|-
; glibc : [ubuntu: libc6-dev (not sure, please check), fedora: glibc-devel]
!Library
; stdc++ library : [ubuntu: libstdc++6-dev (not sure, please check), fedora: libstdc++-devel]
!Debian/Ubuntu
; X11 : [ubuntu: libx11-dev, fedora: libX11-devel]
!Fedora/Red Hat
; zlib : [ubuntu: zlib1g-dev (not sure, please check), fedora: zlib-devel]
|-
; openssl : [ubuntu: libssl-dev, redhat: openssl-devel]
!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
|-
|libidn.so
|libidn11-dev
|libidn11-devel
|}


=== FMOD (audio) ===
==== shortcut commands for the above ====
* FMOD provides audio output, but (although 'free' in some senses) is not itself open-source.  <b>If</b> you wish to avoid FMOD, thus disabling audio, you may make these changes:
** Comment-out the libfmod line in indra/newview/viewer_manifest.py
** Add FMOD=no to your Scons build command when compiling the source.
* If you want to use FMOD, fetch and unpack <b>FMOD 3.75</b> <http://www.fmod.org/>
<code>
% wget http://www.fmod.org/index.php/release/version/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>
<br />
<br />


== Installing the required dependencies (prepackaged by Linden Lab)==
Debian/Ubuntu:


The Second Life Viewer has a number of compile/link dependencies on external libraries which
sudo apt-get install libc6-dev libstdc++6 libx11-dev libxrender-dev libidn11-dev [libgl1-mesa-dev|nvidia-current-dev|...]
are needed - to help you, the source download page contains a link to a <i>slviewer-linux-libs</i> 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 <i>linden</i> folder is after getting and extracting the viewer source code tarball, the following command should unpack everything to the right spot.
Fedora/Red Hat:
<code>
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>


If you choose to use the provided libraries you can skip to
  sudo yum install glibc-devel libstdc++-devel libX11-devel mesa-libGL-devel libXrender-devel libidn11-devel
[[Compiling_the_viewer_%28Linux%29#Compiling|Compiling the client]].
<br />
=== Doing yourself ===
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
listed below.  Paths and package names given here are based on Ubuntu 7.04 and may vary
according to your Linux distribution.


==== List of libraries ====
=== Recommended libraries and headers ===
* <b>apr-1</b> [ubuntu: libapr1-dev, fedora: apr-devel]


* <b>aprutil-1</b> [ubuntu: libaprutil1-dev, fedora: apr-util-devel]
The following packages are required when building standalone, but even if you are building non-standalone you should probably install them.


* <b>boost</b> [ubuntu: libboost-dev, fedora: boost-devel]
{|border="1" cellpadding="5" cellspacing="0"
|-
!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<br/>libcairo.so<br/>libgdk-x11-2.0.so<br/>libgdk_pixbuf-2.0.so<br/>libgmodule-2.0.so<br/>libglib-2.0.so<br/>libgtk-x11-2.0.so<br/>libgthread-2.0.so<br/>libpango-1.0.so<br/>and many more
|libgtk2.0-dev
|atk-devel cairo-devel gtk2-devel glib2-devel pango-devel
|}


* <b>boost-regex</b> [ubuntu: libboost-regex-dev]
==== shortcut commands for the above (2) ====


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


* <b>c-ares</b> library (mandatory for v1.18.4.0, and missing from the pre-compiled libraries package):
<pre><nowiki>
**<http://daniel.haxx.se/projects/c-ares/>
sudo apt-get install libglu1-mesa-dev zlib1g-dev libssl-dev libogg-dev libpng12-dev libdbus-glib-1-dev libgtk2.0-dev
**[ubuntu (gutsy): download Hardy packages and install:
</nowiki></pre>
***<http://packages.ubuntu.com/hardy/libs/libc-ares1>
***<http://packages.ubuntu.com/hardy/libdevel/libc-ares-dev>
<code>
% sudo dpkg -i libc-ares1 && dpkg -i libc-ares-dev
</code>
* <b>ELFIO</b> <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>


* <b>expat</b> [ubuntu: libexpat1-dev, ubuntu (gutsy): libcurl4-openssl-dev, fedora: expat-devel]
Fedora/Red Hat:


* <b>google-perftools</b> library for the tcmalloc and stacktrace libraries. (memory checking)
<pre><nowiki>
**[ubuntu: libgoogle-perftools-dev, fedora: google-perftools-devel.i386
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
</nowiki></pre>


* <b>GTK 2.x</b> development headers [ubuntu: libgtk2.0-dev, fedora: gtk2-devel]
== Necessary libraries when building standalone ==


* <b>jpeglib</b> [ubuntu: libjpeg62-dev, fedora: libjpeg-devel]
=== Existing package names ===


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


* <b>OpenJPEG</b> <http://www.openjpeg.org/>
{|border="1" cellpadding="5" cellspacing="0"
** 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.
|-
*** ''what does this mean?''
!Library
!Debian/Ubuntu
!Fedora/Red Hat
!openSUSE
|-
!libopenal.so
|libopenal-dev
|openal-soft-devel
|openal-soft-devel
|-
!libvorbis.so<br/>libvorbisenc.so<br/>libvorbisfile.so
|libvorbis-dev
|libvorbis-devel
|libvorbis-devel
|-
!libalut.so
|libalut-dev
|freealut-devel
|freealut-devel
|-
!libapr-1.so
|libapr1-dev
|apr-devel
|libapr1-devel
|-
!libaprutil-1.so
|libaprutil1-dev
|apr-util-devel
|libapr-util1-devel
|-
!libboost_program_options.so<br/>libboost_regex.so<br/>libboost_signals.so
|libboost-dev
|boost-devel
|boost-devel
|-
!libcares.so
|libc-ares-dev
|c-ares-devel
|libcares-devel
|-
!libxmlrpc-epi.so
|libxmlrpc-epi-dev
|?
|libxmlrpc-epi0-devel
|-
!libopenjpeg.so
|libopenjpeg-dev
|openjpeg-devel
|openjpeg-devel
|-
!libjpeg.so
|libjpeg62-dev (libjpeg-dev)
|libjpeg-devel
|libjpeg62-devel
|-
!libSDL.so
|libsdl1.2-dev
|SDL-devel
|libSDL-devel
|-
!libgstreamer-0.10.so
|libgstreamer0.10-dev
|gstreamer-devel
|gstreamer-0_10-devel
|-
!gstreamer-0.10 plugins
|libgstreamer-plugins-base0.10-dev
|gstreamer-plugins-base-devel
|gstreamer-0_10-plugins-base-devel
|-
!libgmock.so
|google-mock (Snowglobe 2 only)
|?
|?
|}


* <b>OpenSSL</b> <http://www.openssl.org/> [ubuntu: libssl-dev, fedora: ?]
==== shortcut commands for the above (3) ====


* <b>SDL</b> [ubuntu libsdl1.2-dev, fedora: SDL-devel]
Debian/Ubuntu:


* <b>Vorbis</b> [ubuntu: libvorbis-dev, fedora: libvorbis-devel]
<pre><nowiki>
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
</nowiki></pre>


* <b>xmlrpc-epi 0.51</b> <http://xmlrpc-epi.sourceforge.net/>
Fedora/Red Hat:
** 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]]
*** ''does this still work?''
**** The patches applied OK for me, but didn't result in a usable library.  The patches below appear to work better, except that xmlrpc-epi-0.51-rename.patch didn't apply cleanly (but the manual changes were easy).  I'll update once I get the other dependencies worked out. [[User:Jackson Sadovnycha|Jackson Sadovnycha]] 21:39, 30 August 2007 (PDT)
** See also:
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-gcc4.1.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-use-system-expat.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-rename.patch
*** You have to regenerate autotools after applying the patches:
****libtoolize -c -f
****aclocal
****automake -c -a --foreign
****autoconf
*** The first patch fixes compiling on gcc 4. The second patch causes it to compile against the system expat, the version xmlrpc-epi comes with is broken and will not work. The last patch renames the library from xmlrpc to xmlrpc-epi, otherwise it conflicts with xmlrpc-c - which means the viewer then needs to be patched to link against xmlrpc-epi and not xmlrpc. These patches are from my Fedora package. On linux, I recommend these patches in favor of the Linden ones, as theirs seem to be for windows. (And mine actually work)
<br />
<br />


==== Copy headers and libraries into the source tree ====
<pre><nowiki>
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
</nowiki></pre>


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.
openSUSE:


If you are using the easy <i>slviewer-linux-libs</i> bundle then you can skip the rest of this section, <b>otherwise</b> you will also need to perform the following:
You will have to add the buildservice repository home:lemmy04:snowglobe (http://download.opensuse.org/repositories/home:/lemmy04:/snowglobe/) to your package sources.


* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
<pre><nowiki>
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
sudo zypper install openal-soft-devel libvorbis-devel freealut-devel libapr1-devel libapr-util1-devel \
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.
  boost-devel libcares-devel libxmlrpc-epi0-devel openjpeg-devel libjpeg62-devel libSDL-devel gstreamer-0_10-devel gstreamer-0_10-plugins-base-devel
</nowiki></pre>


<code>
=== More problematic libraries (standalone) ===
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:
Easy so far, now here's where the trouble starts.
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include
Not all required packages are in debian, not to mention you might not even be ''using'' debian
of course; but we (standalone builders) rely for the most part on the tremendous work
done by 64-bit pioneer [[User:Robin_Cornelius]] who happens to use debian. Although many
required packages are now in debian, some still need to be downloaded from Robin's
private repository (assuming you're on debian). TODO: Add instructions for those not
using ubuntu/debian.
<br/>


Edit your <code>/etc/apt/sources.list</code> and add the following lines:


  cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1
  # Repository for SecondLife.
deb <nowiki>http://apt.byteme.org.uk</nowiki> squeeze main
deb-src <nowiki>http://apt.byteme.org.uk</nowiki> squeeze main


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


  mkdir ${SLSRC}/libraries/i686-linux/include/zlib
  # Repository for SecondLife.
  cp -a /usr/include/zlib*.h ${SLSRC}/libraries/i686-linux/include/zlib/
deb <nowiki>http://apt.byteme.org.uk</nowiki> lenny main
  deb-src <nowiki>http://apt.byteme.org.uk</nowiki> lenny main


mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
depending on whether you are using testing (squeeze) or stable (lenny).
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
Note that you won't be able to compile Snowglobe 2.x on lenny because the Qt library is too old.
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/


mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
Run <code>apt-get update</code> to get the Package files from byteme as usual.
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
You can ignore the warning about the missing public key, or do what is
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/
described at the bottom of [http://omvviewer.byteme.org.uk/index.php/downloads/debian/ this page] under 'GPG Keys and Signed repository' (note the remark about not using root), thus:


  mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
  % gpg --keyserver hkp://keyserver.ubuntu.com --recv-key 0x729A79A23B7EE764
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
  % gpg --export 0x729A79A23B7EE764 | sudo apt-key add -
  touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h


mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
or for ubuntu users we use the openmetaverse repo, run this command to add the repo:
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
  # Openmetaverse repo
  cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
  sudo add-apt-repository ppa:openmetaverse/ppa


# For SL v1.18.4.0:
'''NOTE:''' If you are on Ubuntu 12.04 ("Precise") you will also need to edit the file /etc/apt/sources.list.d/openmetaverse-ppa-precise.list so that it refers to the "lucid" distro instead of "precise" because the maintainers haven't made packages for "precise" yet.
mkdir ${SLSRC}/libraries/i686-linux/include/ares
cp -a /usr/include/ares* ${SLSRC}/libraries/i686-linux/include/ares/
cp -a /usr/lib/libcares.* ${SLSRC}/libraries/i686-linux/lib_release_client/
</code>
<br />
<br />


== Compiling ==
Change /etc/apt/source.list.d/openmetaverse-ppa-precise.list from:
=== Build Types ===
The ''BUILD'' parameter specifies the build type. For normal usage, use '''release'''. If you plan to work on the source, choose '''releasenoopt''' or '''debug''', as these versions are unoptimized and much easier to debug.


You can also edit the scons file to cause releasefordownload to skip the "stripping" step, for a version that is relatively easy to debug, yet still performs well.
deb http://ppa.launchpad.net/openmetaverse/ppa/ubuntu precise main
deb-src http://ppa.launchpad.net/openmetaverse/ppa/ubuntu precise main


* '''release''': Optimized build for release.
To be:
* '''releasenoopt''': Unoptimized build.
* '''debug''': Debug build with assertions.
* '''releasefordownload''': Optimized build for release, will create a .tar.gz with the files for distribution.
<br />
=== Building ===
=== Enabling llMozLib ===
Add MOZLIB=yes to your Scons build command when compiling the source.  Failure to do this will cause errors on some versions, due to badly structured ifdefs in the code.  If you really don't want mozlib you must apply the patches attached to VWR-3748.
<br />
<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=yes
</code>
Expect a build time of a couple of hours.  The resulting unstripped Second Life Viewer binary is <b>newview/secondlife-i686-bin</b>. Note that temporary object code is compiled into <b>/tmp/$USER</b> by default (where $USER is your username) - this can be changed by prefixing the <b>scons</b> command above with <b>TEMP_BUILD_DIR="<i>[full directory path]</i>"</b>. For example:


<code>
deb http://ppa.launchpad.net/openmetaverse/ppa/ubuntu lucid main
  $ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
  deb-src http://ppa.launchpad.net/openmetaverse/ppa/ubuntu lucid main
</code>


To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux client, use BUILD=releasefordownload
and of course to add the keys ('''only on Debian''')


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.
gpg --keyserver hkp://keyserver.ubuntu.com --recv-key 0x50A40F50
<br />
gpg --export 0x50A40F50 | sudo apt-key add -
<br />


== Testing and packaging the client ==
and always remember to update after adding repos


=== Testing the result from inside the tree ===
apt-get update


You may find it simpler and less error-prone to follow the instructions in the [[Compiling_the_viewer_%28Linux%29#Packaging_the_client|Packaging the client]] section below to run the client under the same conditions as an end-user would.
Finally install these packages:


* 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.
{|border="1" cellpadding="5" cellspacing="0"
|-
!Library
!Debian/Ubuntu
|-
!libcurl-cares.so
|libcurl4-cares-dev
|-
!llqtwebkit
|libllqtwebkit-dev (Snowglobe 1) or<br/>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)
|}
<br/>


Otherwise:
Shortcut commands for the above


* Preparing to run 'in-tree'
sudo apt-get install libcurl4-cares-dev libllqtwebkit2-dev glh-linear boost-coroutine libndofdev-dev
** <i>ensure that you have indra/newview/app_settings/static_*.db2</i> - 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/
$ cp ../etc/message.xml newview/app_settings/
</code>


'''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.
If you are on lenny you will also (automatically) install the packages '''cmake''', '''libopenjpeg-dev''' and '''libopenjpeg2''' from byteme. This is because the packages in lenny contain bugs.


* Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places.  From the indra directory:
The libjsoncpp-dev installs a library called <code>/usr/lib/libjson.so</code>, but the viewer is looking for one called <code>libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so</code> in '/usr/lib' and '/usr/local/lib'. Therefore execute the following command as root:
<code>
$ ( 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 )
</code>


<br />
# This is not needed on Snowglobe 1.4.1 and higher.
==== The client seems kinda slow. ====
% ln -s /usr/lib/libjson.so /usr/local/lib/libjson_linux-gcc-$(g++ -dumpversion)_libmt.so


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.
In order to run the tests, you need a template library called 'tut'. Because this is a template library, we can just use the library archive from Linden Lab for any architecture. Therefore, to install tut, run:


However, the <i>slviewer-linux-libs</i> package includes two pre-built libraries which facilitate the use of this slightly faster image decoding method: <b>libkdu_v42R.so</b> and <b>libllkdu.so</b>.  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.
% scripts/install.py tut


To <b>use these faster image-decoding libraries</b>, 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:
Until recently for some completely mysterious reason, the source code includes <code><tut/tut.hpp></code> while
<code>
configure checks for <code>tut.h</code> in <code>/usr/lib</code> and <code>/usr/local/lib</code> only (CXXFLAGS?
cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
Never heard of that).
mkdir "$SLSRC/indra/lib"
In order to fix this brokenness for non-Snowglobe viewers or based on older snowglobe versions (prior to 1.4, or 2.1),
cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"
execute the following (2.x viewers older than 2.1 and 1.x viewers older than 1.4 only):
</code>


The file <b>indra/newview/viewer_manifest.py</b> 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.
# This is not needed on Snowglobe 1.4.1 and higher.
% sudo touch /usr/local/include/tut.h


==== File Dialogs Don't Work on 64 bit system ====
which satisfies the configure check. The installed tut.hpp is still used anyway since <code>libraries/include</code> is in the include search path by default. Alternatively, edit <code>indra/cmake/Tut.cmake</code> and comment out these two lines:


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:
<code>
<code>
2007-06-21T01:28:35Z INFO: ll_try_gtk_init: Starting GTK Initialization.
  #include(FindTut)
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: GTK Initialized.
  #include_directories(${TUT_INCLUDE_DIR})
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)
</code>
</code>


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.
Oh WAIT! On 2.0 standalone <code>libraries/include</code> is NOT included anymore, and it seems impossible
to fix the cmake spaghetti so here's what you have to do on top of the above:


Possible solutions:
sudo cp -r libraries/include/tut /usr/local/include
* 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 ===
Sorry but there is no other way.


If you substitute 'BUILD=release' with '<b>BUILD=releasefordownload</b>' 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 <b>indra/newview/SecondLife_i686_1_X_Y_Z/</b> and has also been tarred into <b>indra/newview/SecondLife_i686_1_X_Y_Z.tar.bz2</b>
However, if you are using snowglobe 1.4 or a later 1.x, or snowglobe 2.1 or later, or a viewer based on those,
then the viewer actually looks for tut/tut.hpp. So, you can still install it in <code>/usr/local/include/tut/</code>,
but you can also install it in -say- /somewhere/include/tut/ and set the environment variable CMAKE_INCLUDE_PATH
(a colon separated list of paths) to include <code>/somewhere/include</code> before configuration. Note that due to
a cmake problem/bug it will find /somewhere/include but ''still'' use the include path of any other library,
including /usr/include or /usr/local/include, so make sure you remove any other tut installation from common
paths if you use the latter method.


The file which controls what (and where) files go into the end-user runtime viewer directory is <b>indra/newview/viewer_manifest.py</b>
=== 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 slvoice


==== Automated libraries and headers adjustments, compilation and packaging ====
{{KBnote|In earlier revisions, the package was named <code>vivox</code> rather than <code>slvoice</code>.}}


<br>
After [[#Compiling|building]], you'll have to copy the binaries into the right place
Here are two bash scripts (one for v1.20 and earlier viewers, and one for v1.21 and later) that could save you a lot of time... They basically does all what is described above, and more, and entitle you to compile a SL client very easily:
(-- 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 --[[User:Aleric Inglewood|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/


<b>IMPORTANT NOTE:</b>
If you want, you can then remove the voice binaries again from the source tree with
${SOURCE_DIR}/scripts/install.py --uninstall vivox


These script includes instructions which have the potential to remove MANY files on your system should you modify them without understanding exactly what it does (i.e. rm -rf $VARIABLE/ where entire portions of your filesystem *will* be deleted without warning).  This is not a theoretical problem, this script has caused damage to unwary users already.
=== Remaining issues (standalone) ===


Although some basic checks are done to avoid removing an entire home directory, or even the root tree, this script is not meant to be tweaked without a very good knowledge of bash scripting. It is therefore highly recommended that you use it without modifying the PATH_TO_SOURCES and TEMP_BUILD_DIR variables (modifying the USE_* and TUNE_FLAGS variables is safe).
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 <code>indra/newview/viewer_manifest.py</code> and comment out the following lines in <code>class Linux_i686Manifest(LinuxManifest)</code>:


<code>
<pre><nowiki>
<pre>
            #self.path("libapr-1.so.0")
<nowiki>
            #self.path("libaprutil-1.so.0")
#!/bin/bash
            #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")


# make-SL v1.84 (c)2007-2008 Henri Beauchamp. Released under GPL license v2:
            # Vivox runtimes
# http://www.gnu.org/licenses/gpl.txt
            #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")
</nowiki></pre>


###############################################################################
Also, until [http://jira.secondlife.com/browse/VWR-9475 VWR-9475] ''really'' gets fixed (it was fixed before, but not really),
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
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
# BEWARE: this script is meant to compile a -personal- SL client. It is -NOT- #
#        suitable to build client versions meant for public release, because #
#        non-open source code is packaged by this script (e.g. libkdu).      #
###############################################################################


# This bash script is aimed at easying up the build process of a SL client.
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/).
# 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
== Installing the Non-Free Shared Libraries ==
# put it into /usr/local/bin (or any other directory in your PATH).
'''Needs to be redone''' - [[User:Oz Linden|Oz Linden]]
# 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.
# The packaged build will be moved to your home 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, and a (no less customized but yet more standard)
# Mandriva 2007.1 distro.
# Tested with SL v1.17, v1.18, v1.19 & v1.20 sources.


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


USE_SYSTEM_GTK="no"
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.
USE_SYSTEM_SDL="no"
USE_SYSTEM_SSL="no"
# Beware: libdb4 makes use of libapr, and libapr makes use of libexpat... so
# you should keep USE_SYSTEM_APR, USE_SYSTEM_DB4 and USE_SYSTEM_EXPAT in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_OGG="no"
USE_SYSTEM_ZLIB="no"
USE_SYSTEM_UUID="no"
# If your system libcurl does not use c-ares (non-blocking DNS calls), better
# using LL's provided library...
USE_SYSTEM_CURL="no"
USE_SYSTEM_VORBIS="no"
USE_SYSTEM_XMLRPC="no"
USE_SYSTEM_JPEGLIB="no"
# Enabling the system freetype2 prevents the client from using the SL fonts,
# or at least, this is what happens on my system (Mandrake 10.2 and Mandriva
# 2007.1 with PLF's freetype2).
USE_SYSTEM_FREETYPE2="no"
USE_SYSTEM_PERFTOOLS="no"


# You may add tune flags here, to optimize the code for your processor.
'''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)]]
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp"
# BEWARE: because of a bug in the v1.17.2.0 SConstruct file, you MUST keep at
# least an -O2 flag in the TUNE_FLAGS, to avoid getting a very slooooow client...
# This problem was apparently fixed in v1.17.3.0.
TUNE_FLAGS="-fomit-frame-pointer -frename-registers -fweb -fexpensive-optimizations -march=i686 -msse -mfpmath=sse"
# Set this to "yes" to force vectorization use in the viewer code (only for
# processors with SSE or Altivec units, and only if you did enable them via
# the TUNE_FLAGS.
FORCE_VECTORIZE="yes"


# Whether to build with the browser login screen or not:
== Build the viewer with autobuild ==
WITH_MOZILLA="yes"
Configuring and building with autobuild works the same on all platforms.  Full instructions may be found at [[Build_Viewer_With_Autobuild]].


########### functions definitions ###########
{{KBcaution| If you are using prepackaged 3rd party libraries from Linden (not a stand alone build) then you will need to build using gcc version 4.1; set CC and CXX accordingly. ''TODO: expand/update''}}


function check() {
=== Configuration notes ===
    if [ "$1" == "yes" ] ; then
* To build for 'standalone' (see `[[#What_does_.27Standalone.27_mean.3F|What does 'standalone' mean?]]` above) choose an '''OpenSourceStandAlone''' option.
        if [ -f $2 ] ; then
* If you want to use KDevelop add <code>-G KDevelop3</code>.
            echo "Using the system $3..."
* 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.
            return 0
* '''OpenSource''' configurations do not install FMOD (which will be disabled).
        else
* The environment variables CC and CXX are picked up automatically as usual. However, this is not the case of CXXFLAGS and LDFLAGS. You can pass the following to the configure commandline: <code>-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" -DCMAKE_EXE_LINKER_FLAGS:STRING="$LDFLAGS"</code> to enable the use of these environment variables.
            echo "WARNING: system $3 requested but not available..."
* You can make the build process more verbose (make it print the compiler commands it executes) by passing <code>-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON</code> as well.
        fi
* As of version 2.0, passing <code>-DLL_TESTS:BOOL=FALSE</code> will stop running any tests (if any; depends on standalone and viewer version).
    fi
* If you want to restart the configuration process from scratch without any cached values affecting the configuration, erase the <code>CMakeCache.txt</code> in the build directory.
    return 1
* Autobuild appears to bind the CXX and CC env. variables at configuration time.  So the following should work if done once:
}
**  CXX=g++-4.1 CC=gcc-4.1 autobuild configure -c Release


function update_manifest() {
=== Where's the built viewer? ===
    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
    chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}


function compile() {
On Linux, your build will be at
    cd $PATH_TO_SOURCES/indra
    echo "Compiling the client into $TEMP_BUILD_DIR..."
    scons DISTCC=no BTARGET=client OPENSOURCE=no BUILD=releasefordownload CHANNEL=Release MOZLIB=$WITH_MOZILLA MOZLIB2=$WITH_MOZILLA
    if (($? == 0)) ; then
        mv $PATH_TO_SOURCES/indra/newview/SecondLife*.tar.bz2 $HOME/
    fi
}


########### end of functions ###########
build-linux-ARCH/newview/packaged


if [ "$TEMP_BUILD_DIR" == "" ] ; then
where "''ARCH''" should be something like "i686" or "x86_64" (depending on your platform).
    export TEMP_BUILD_DIR=/tmp/$USER/SL
{{KBcaution|Currently, the build dir will be <code>build-linux-'''i686'''</code>, even when a 64-bit build was requested by <code>autobuild configure [...] -- -DWORD_SIZE{{=}}64 [...]</code>. See {{jira|OPEN-106}}.}}
fi


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


# Make sure we don't unpack over an old source tree:
It is very highly recommended that you use and install [http://ccache.samba.org/manual.html ccache] even before
if [ -d linden ] ; then
the first compile; it will speed up subsequent compiles with a factor of 10 in case you need to redo the compile!
    rm -rf linden/
fi


if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
The easiest way to start using ccache is to make ''symbolic'' links to ccache
    rm -rf $PATH_TO_SOURCES/
from <code>/usr/local/bin</code>. Make sure that <code>/usr/local/bin</code> comes first in your <code>PATH</code>,
fi
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),


# Use the parameter (if any) as the path to the archives:
<code>
% apt-get install ccache
% cd /usr/local/bin
% ln -s ../../bin/ccache gcc
% ln -s ../../bin/ccache g++
</code>


PATH_TO_ARCHIVES="."
And then to test, as normal user (make sure you are not in /usr/local/bin anymore),
if [ "$1" != "" ]; then
    if [ -d $1 ] ; then
        PATH_TO_ARCHIVES=$1
    fi
fi


# Let's first unpack everything:
<code>
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
% which g++
    echo "You need slviewer-src !"
</code>
    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 -o $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
# You may add artwork patches named in the form:
# slviewer-whatever-artwork-patch.zip
# Example: slviewer-v11900-statusbar-artwork-patch.zip
ARTWORK_PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*-artwork-patch.zip`
if [ "$ARTWORK_PATCHES" != "" ] ; then
    for f in $ARTWORK_PATCHES; do
        echo "Extracting artwork patch $f..."
        unzip -o $f >/dev/null
    done
fi


# fmodapi:
This should print <code>/usr/local/bin/g++</code>, if not fix you <code>PATH</code>.
echo "Copying fmodapi files..."
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz
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:
Note that by default ccache puts the cache in <code>$HOME/.ccache</code> and will grow till about 1 GB, so make sure you have that diskspace there. Alternatively you can set the environment variable <code>CCACHE_DIR</code> to change the location of the cache.
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:
=== Using distcc ===
chown -R $USER: $PATH_TO_SOURCES/


# Check for patches to apply. The names of the patches must be in the form
If you have multiple PCs, you can speed up the build process by using distcc.
# slviewer-*.patch* (Example: slviewer-v117-EmbbededNotecard.patch.bz2).
You probably should ''still'' use ccache which has to be run before distcc, therefore
# They must be applicable from inside the source directory with the -p1
both have to be specified in the <code>CXX</code> environment variable, by adding ccache to them.
# option, i.e. they have been built from outside the source directory
# with a diff command such as:
# diff -urN linden/ linden-patched/ >slviewer-whatever.patch
# And they may be gzipped or bzipped.
PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch* 2>/dev/null`
if [ "$PATCHES" != "" ] ; then
    echo "Applying patches..."
    cd $PATH_TO_SOURCES
    PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch*`
    for i in $PATCHES; do
        echo "Patch: $i"
        if echo $i | grep ".gz" &>/dev/null ; then
            gunzip -c $i | patch -p1 -s
        elif echo $i | grep ".bz2" &>/dev/null ; then
            bzcat $i | patch -p1 -s
        else
            patch -p1 -s <$i
        fi
    done
fi


# Make a clean build:
To use distcc, you need to pass an environment variable <code>CXX</code> containing the distcc command prefix to <code>develop.py</code> when configuring, e.g.,
if [ -d $TEMP_BUILD_DIR ] && [ "$TEMP_BUILD_DIR" != "" ] && [ "$TEMP_BUILD_DIR" != "/" ] && [ "$TEMP_BUILD_DIR" != "." ] && [ "$TEMP_BUILD_DIR" != ".." ] && [ "$TEMP_BUILD_DIR" != "$HOME" ] ; then
    rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR


# In v1.18.4.0, they use c-ares but fail to provide it in the library package...
CXX="ccache distcc g++" ./develop.py configure
if [ -f $PATH_TO_SOURCES/indra/llcommon/llares.cpp ] ; then
    if ! [ -f $PATH_TO_SOURCES/libraries/i686-linux/include/ares/ares_dns.h ] && ! [ -f $PATH_TO_SOURCES/libraries/include/ares/ares_dns.h ] ; then
        if [ -f /usr/include/ares_dns.h ] && [ -f /usr/lib/libcares.a ] ; then
            echo "Copying missing c-ares files from the system..."
            cd $PATH_TO_SOURCES/libraries/i686-linux
            mkdir include/ares
            cp -a /usr/include/ares* include/ares/
            cp -a /usr/lib/libcares* lib_release_client/
        else
            echo "Sorry... You need c-ares installed in your system to compile this version of the client."
            echo "Try: http://daniel.haxx.se/projects/c-ares/"
            exit 1
        fi
    fi
fi


# Let's use the system GTK+ if available:
Or, if you are using a heterogeneous rows of PCs, you need to add a config prefix to <code>g++</code>, e.g. (in my case, as a Fedora user),
if check $USE_SYSTEM_GTK /usr/include/atk-1.0/atk/atk.h "GTK+" ; then
    cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
    rm -f libgtk* libgdk* libglib* libgmodule* libgobject* libgthread* libpango* libatk*
    cd ../include
    rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
    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:
CXX="ccache distcc i386-redhat-linux-g++" ./develop.py configure
if check $USE_SYSTEM_FREETYPE2 /usr/include/ft2build.h "freetype2" ; then
    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:
Once you did so, the generated makefiles contain instructions to use distcc.  You don't need to specify anything special when invoking <code>develop.py</code> to build.  The number of concurrent jobs (i.e., <code>-j</code> option to <code>make</code> command) to run is automatically determined by <code>develop.py</code>.
if check $USE_SYSTEM_ZLIB /usr/include/zlib.h "zlib" ; then
    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 you invoke <code>make</code> command by yourself, don't forget to add the <code>-j</code> option with an appropriate number.
if check $USE_SYSTEM_JPEGLIB /usr/include/jpeglib.h "jpeglib" ; then
    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:
= What to do if it doesn't work for you =
if check $USE_SYSTEM_XMLRPC /usr/include/xmlrpc.h "xmlrpc-epi" ; then
    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:
* Ask for help on [[IRC]] (irc.freenode.net #opensl)
if check $USE_SYSTEM_OGG /usr/include/ogg/ogg.h "ogg" ; then
* Find someone on the [[OpenSource-Dev|opensource-dev mailing list]]
    cd $PATH_TO_SOURCES/libraries
* Fix it: [[Modifying CMake Files‎]] (and please, submit a patch!)
    rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
* If you are building on openSUSE 11.2 or newer, and your builds fail with lots of "undefined reference to ..." message: set the environment variable SUSE_ASNEEDED to 0 before building.
    update_manifest libogg
fi


# Let's use the system vorbis if available:
= Submitting Patches =
if check $USE_SYSTEM_VORBIS /usr/include/vorbis/vorbisenc.h "vorbis" ; then
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|submitting patches]].
    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 check $USE_SYSTEM_SDL /usr/include/SDL/SDL.h "SDL" ; then
    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:
{{KBcaution|
if check $USE_SYSTEM_SSL /usr/include/openssl/opensslconf.h "openssl" ; then
Everything below is probably outdated. It should be carefully sorted, cleaned up, updated and deleted (added 14/7/2010)
    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:
= Prebuilt libraries vs. standalone builds =
if check $USE_SYSTEM_APR /usr/include/apr*/apr_base64.h "apr" ; then
    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 db4 if available:
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.
if check $USE_SYSTEM_DB4 /usr/include/db4/db.h "db4" ; then
    rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
    update_manifest libdb
fi


# Let's use the system expat if available:
* [[Building_the_viewer_with_CMake/cmake-SL_script|cmake-SL]]: a script for standalone, pre-built and mixed libraries viewer builds under Linux.
if check $USE_SYSTEM_EXPAT /usr/include/expat.h "expat" ; then
* [[Talk:CMake#Issues_when_compiling_a_standalone_Linux_viewer|Problems when compiling a standalone Linux viewer]]
    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 check $USE_SYSTEM_CURL /usr/include/curl/curl.h "curl" ; then
    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 uuid if available:
== Testing and packaging the client ==
if check $USE_SYSTEM_UUID /lib/libuuid.so.1 "libuuid" ; then
    rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
    update_manifest libuuid
fi


if grep tcmalloc $PATH_TO_SOURCES/indra/SConstruct &>/dev/null ; then
=== Testing the result from inside the tree ===
    if check $USE_SYSTEM_PERFTOOLS /usr/include/google/malloc_hook.h "google-perftools" ; then
        cd $PATH_TO_SOURCES/libraries/i686-linux
        rm -f lib_release_client/libtcmalloc.* lib_release_client/libstacktrace.*
        rm -rf include/google/
        cp -a /usr/lib/libstacktrace.* /usr/lib/libtcmalloc.so* lib_release_client/
        cp -a /usr/include/google include/
        update_manifest tcmalloc
        update_manifest stacktrace
    else
        # Remove the google-perftools stuff if not present in the libraries package
        # (problem seen in SL v1.17):
        if ! [ -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libtcmalloc.so ] ; then
            update_manifest tcmalloc
            update_manifest stacktrace
            # The following lines remove the
            #  "external_libs += ['tcmalloc', 'stacktrace']"
            # line from SConstruct... and many other lines which renders SConstruct
            # unusable to build anything else than the client... this is a quick'n
            # dirty patch. :-P
            grep -v tcmalloc $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
            mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
        fi
    fi
fi


# Fix a bug in v1.17.1 and later SConstruct file, where some libraries are
You may find it simpler and less error-prone to follow the instructions in the [[Compiling_the_viewer_%28Linux%29#Packaging_the_client|Packaging the client]] section below to run the client under the same conditions as an end-user would.
# compiled as shared instead of static, and are yet not packaged, and where
# fmod can't be enabled for OPENSOURCE:
sed -e "s/create_dynamic_module(module=module, module_libs=module_libs)/create_static_module(module)/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
sed -e "s/enable_fmod = not opensource and/enable_fmod =/" $TEMP_BUILD_DIR/SConstruct >$PATH_TO_SOURCES/indra/SConstruct
rm -f $TEMP_BUILD_DIR/SConstruct


# Add tune flags, if any:
* 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.
if [ "$TUNE_FLAGS" != "" ] ; then
    sed -e "s/-pipe/$TUNE_FLAGS -pipe/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
    mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi


# Force the vectorization use if we chose so.
Otherwise:
if [ "$FORCE_VECTORIZE" == "yes" ] ; then
    sed -e "s/cflags += '-m32 '/cflags += '-m32 -DLL_VECTORIZE=1 '/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
    mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi


# Use whatever gcc version we got.
* Preparing to run 'in-tree'
sed -e "s/g++-3.4/g++/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
** <i>ensure that you have indra/newview/app_settings/static_*.db2</i> - if not, you'll find it in the [[#slviewer-artwork-.3Cversion.3E.zip|slviewer-artwork]] download (a zip file).
sed -e "s/g++-4.1/g++/" $TEMP_BUILD_DIR/SConstruct >$PATH_TO_SOURCES/indra/SConstruct
** now, from the indra directory:
rm -f $TEMP_BUILD_DIR/SConstruct
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
$ cp ../etc/message.xml newview/app_settings/
</code>


# Fix boost library linking problems in v1.20
'''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.
sed -e "s/-gcc34-mt//g" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct


# Update the manifest file and enable libkdu packaging. I'm too lazy to use
* Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:
# awk or perl, here, but that's indeed what should be done...
<code>
# The following (very dirty) code may break at some point, depending on what
$ ( 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 )
# LL will put in comments in the manifest file...
</code>
# 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/#        them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
sed -e "s/#  /   /" $TEMP_BUILD_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
rm -f $TEMP_BUILD_DIR/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py


# Comment out "export LL_GL_BASICEXT=x" in the wrapper script:
<br />
sed -e "s/export LL_GL_BASICEXT=x/#export LL_GL_BASICEXT=x/" $PATH_TO_SOURCES/indra/newview/linux_tools/wrapper.sh >$TEMP_BUILD_DIR/wrapper.sh
==== The client seems kinda slow. ====
mv -f $TEMP_BUILD_DIR/wrapper.sh $PATH_TO_SOURCES/indra/newview/linux_tools/wrapper.sh
chmod +x $PATH_TO_SOURCES/indra/newview/linux_tools/wrapper.sh


# Missing file... at least in v1.17.0.0
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.
if grep "secondlife-i686.supp" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py &>/dev/null ; then
    if ! [ -f $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp ] ; then
        touch $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp
    fi
fi


# LL makes the assumption that a certain unicode true type font is installed
However, the [[#slviewer-linux-libs-.3Cversion.3E.tar.gz|slviewer-linux-libs]] package includes two pre-built libraries which facilitate the use of this slightly faster image decoding method: <b>libkdu_v42R.so</b> and <b>libllkdu.so</b>. 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.
# on all Linux systems... which is of course wrong !  Let's check, and when
# this font is absent, replace the broken soft link with an empty file: this
# at least will prevent the viewer to issue many warnings about not being able
# to load the unicode.ttf font.
if ! [ -r $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf ] ; then
    rm -f $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf
    touch $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf
fi


compile
To <b>use these faster image-decoding libraries</b>, 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:
</nowiki>
<code>
</pre>
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>
</code>
<br />
And now for compiling with cmake (v1.21 and later viewers):


<code>
The file <b>indra/newview/viewer_manifest.py</b> 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.
<pre>
<nowiki>
#!/bin/bash


# cmake-SL v1.10 (c)2008 Henri Beauchamp. Released under GPL license v2:
==== File Dialogs Don't Work on 64 bit system ====
# http://www.gnu.org/licenses/gpl.txt


###############################################################################
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:
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
<code>
###############################################################################
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)
</code>


###############################################################################
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.
# BEWARE: this script is meant to compile a -personal- SL client. It is -NOT- #
#        suitable to build client versions meant for public release, because #
#        non-open source code is packaged by this script.                   #
###############################################################################


# This bash script is aimed at easying up the build process of a SL client
Possible solutions:
# with cmake.
* Download the source for the version of the 32 bit GTK libraries your distribution comes with, and build your viewer against those headers.
# You may enable or disable the use of your system's library by editing
* Upgrade your 32 bit GTK package so that it's the same or newer as the 64 bit one.
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
* Downgrade your 64 bit package (may not be a good idea).
# 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 cmake-SL) and
=== Packaging the client ===
# 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:
#  cmake-SL path_to_archives  (example: make-SL ~/downloads)
# or simply:
#  cmake-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_DIR directory.
# The packaged build will be moved to your home directory.
#
# If you want to retry a compilation after fixing something manually and
# don't want cmake-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
#  cmake-SL --retry
#
# Finally, if you just want to prepare the sources without starting the
# compilation, use:
#  cmake-SL --prep
#
# This script has been tested by the author, on a (very customized)
# Mandriva 2007.1 distro.
# Tested with SL v1.21 sources.


# Where the sources of the client will be held (defaults to "./linden"):
If you substitute 'BUILD=release' with '<b>BUILD=releasefordownload</b>' 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 <b>indra/newview/SecondLife_i686_1_X_Y_Z/</b> and has also been tarred into <b>indra/newview/SecondLife_i686_1_X_Y_Z.tar.bz2</b>
PATH_TO_SOURCES="/usr/src/SL"
# Where to store temporary files:
TEMP_DIR="/usr/tmp/$USER"


USE_SYSTEM_GTK="no"
The file which controls what (and where) files go into the end-user runtime viewer directory is <b>indra/newview/viewer_manifest.py</b>
USE_SYSTEM_SDL="no"
USE_SYSTEM_SSL="no"
# Beware: libdb4 makes use of libapr, and libapr makes use of libexpat... so
# you should keep USE_SYSTEM_APR, USE_SYSTEM_DB4 and USE_SYSTEM_EXPAT in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_OGG="no"
USE_SYSTEM_ZLIB="no"
USE_SYSTEM_UUID="no"
# If your system libcurl does not use c-ares (non-blocking DNS calls), better
# using LL's provided library...
USE_SYSTEM_CURL="no"
USE_SYSTEM_VORBIS="no"
USE_SYSTEM_XMLRPC="no"
USE_SYSTEM_JPEGLIB="no"
USE_SYSTEM_PERFTOOLS="no"
USE_SYSTEM_LIBSTDC="no"
 
# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp"
TUNE_FLAGS="-fomit-frame-pointer -frename-registers -fweb -fexpensive-optimizations -march=i686 -msse -mfpmath=sse"
# Set this to "yes" to force vectorization use in the viewer code (only for
# processors with SSE or Altivec units, and only if you did enable them via
# the TUNE_FLAGS.
FORCE_VECTORIZE="yes"
 
########### functions definitions ###########
 
function check() {
    if [ "$1" == "yes" ] ; then
        if [ -f $2 ] ; then
            echo "Using the system $3..."
            return 0
        else
            echo "WARNING: system $3 requested but not available..."
        fi
    fi
    return 1
}
 
function update_manifest() {
    grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_DIR/viewer_manifest.py
    mv -f $TEMP_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
    chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}
 
function compile() {
    cd $PATH_TO_SOURCES/indra
    echo "Compiling the client into $TEMP_DIR..."
    ./develop.py --type=Release build
    if (($? == 0)) ; then
        mv -f $PATH_TO_SOURCES/indra/viewer-linux-i686/newview/SecondLife*.tar.bz2 $HOME/
    fi
}
 
########### end of functions ###########
 
if [ "$TEMP_DIR" == "" ] ; then
    export TEMP_DIR="/usr/tmp/$USER"
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" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
    rm -rf $PATH_TO_SOURCES/
fi
 
# Use the parameter (if any) as the path to the archives:
 
PATH_TO_ARCHIVES=`pwd`
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 -o $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
# You may add artwork patches named in the form:
# slviewer-whatever-artwork-patch.zip
# Example: slviewer-v11900-statusbar-artwork-patch.zip
ARTWORK_PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*-artwork-patch.zip`
if [ "$ARTWORK_PATCHES" != "" ] ; then
    for f in $ARTWORK_PATCHES; do
        echo "Extracting artwork patch $f..."
        unzip -o $f >/dev/null
    done
fi
 
# fmodapi:
echo "Copying fmodapi files..."
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz
mkdir -p linden/libraries/include/
mkdir -p linden/libraries/i686-linux/lib_debug/
mkdir -p linden/libraries/i686-linux/lib_release/
mkdir -p linden/libraries/i686-linux/lib_release_client/
cp -a fmodapi*/api/inc/* linden/libraries/include/
cp -a 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/
 
# Check for patches to apply. The names of the patches must be in the form
# slviewer-*.patch* (Example: slviewer-v117-EmbbededNotecard.patch.bz2).
# They must be applicable from inside the source directory with the -p1
# option, i.e. they have been built from outside the source directory
# with a diff command such as:
# diff -urN linden/ linden-patched/ >slviewer-whatever.patch
# And they may be gzipped or bzipped.
PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch* 2>/dev/null`
if [ "$PATCHES" != "" ] ; then
    echo "Applying patches..."
    cd $PATH_TO_SOURCES
    PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch*`
    for i in $PATCHES; do
        echo "Patch: $i"
        if echo $i | grep ".gz" &>/dev/null ; then
            gunzip -c $i | patch -p1 -s
        elif echo $i | grep ".bz2" &>/dev/null ; then
            bzcat $i | patch -p1 -s
        else
            patch -p1 -s <$i
        fi
    done
fi
 
cd $PATH_TO_SOURCES/indra
 
# Do a clean build
./develop.py clean
 
# Force the vectorization use if we chose so.
if [ "$FORCE_VECTORIZE" == "yes" ] ; then
    TUNE_FLAGS="$TUNE_FLAGS -DLL_VECTORIZE=1"
fi
# Configure the sources and download the LL provided libraries:
./develop.py --type=Release  configure \
    -DCMAKE_C_FLAGS:STRING="-O2 $TUNE_FLAGS" -DCMAKE_CXX_FLAGS:STRING="-O2 $TUNE_FLAGS" \
    -DCMAKE_C_FLAGS_RELEASE:STRING="-O2 $TUNE_FLAGS" -DCMAKE_CXX_FLAGS_RELEASE:STRING="-O2 $TUNE_FLAGS" \
    -DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING="-g -O2 $TUNE_FLAGS" -DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING="-g -O2 $TUNE_FLAGS"
 
# Let's use the system GTK+ if available:
if check $USE_SYSTEM_GTK /usr/include/atk-1.0/atk/atk.h "GTK+" ; then
    cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
    rm -f libgtk* libgdk* libglib* libgmodule* libgobject* libgthread* libpango* libatk*
    cd ../include
    rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
    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 zlib if available:
if check $USE_SYSTEM_ZLIB /usr/include/zlib.h "zlib" ; then
    cd $PATH_TO_SOURCES/libraries
    rm -rf include/zlib/
    rm -f i686-linux/lib_release_client/libz.so.1
    mkdir -p include/zlib
    cp -a /usr/include/zlib*.h include/zlib/
fi
 
# Let's use the system jpeglib if available:
if check $USE_SYSTEM_JPEGLIB /usr/include/jpeglib.h "jpeglib" ; then
    cd $PATH_TO_SOURCES/libraries
    rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
    mkdir -p include/jpeglib
    cp -a /usr/include/j*.h include/jpeglib/
    touch include/jpeglib/jinclude.h
fi
 
# Let's use the system xmlrpc-epi if available:
if check $USE_SYSTEM_XMLRPC /usr/include/xmlrpc.h "xmlrpc-epi" ; then
    cd $PATH_TO_SOURCES/libraries
    rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
    mkdir -p include/xmlrpc-epi
    cp -a /usr/include/xmlrpc*.h include/xmlrpc-epi/
fi
 
# Let's use the system ogg if available:
if check $USE_SYSTEM_OGG /usr/include/ogg/ogg.h "ogg" ; then
    cd $PATH_TO_SOURCES/libraries
    rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
fi
 
# Let's use the system vorbis if available:
if check $USE_SYSTEM_VORBIS /usr/include/vorbis/vorbisenc.h "vorbis" ; then
    cd $PATH_TO_SOURCES/libraries
    rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
fi
 
# Let's use the system SDL if available:
if check $USE_SYSTEM_SDL /usr/include/SDL/SDL.h "SDL" ; then
    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 check $USE_SYSTEM_SSL /usr/include/openssl/opensslconf.h "openssl" ; then
    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 check $USE_SYSTEM_APR /usr/include/apr*/apr_base64.h "apr" ; then
    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 db4 if available:
if check $USE_SYSTEM_DB4 /usr/include/db4/db.h "db4" ; then
    rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
    update_manifest libdb
fi


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


# Let's use the system curl if available:
== Resident contributed instructions ==
if check $USE_SYSTEM_CURL /usr/include/curl/curl.h "curl" ; then
    cd $PATH_TO_SOURCES/libraries
    rm -rf include/curl/
    rm -f i686-linux/lib_release_client/libcurl.*
fi


# Let's use the system uuid if available:
=== Automated libraries and headers adjustments, compilation and packaging ===
if check $USE_SYSTEM_UUID /lib/libuuid.so.1 "libuuid" ; then
    rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
    update_manifest libuuid
fi


# Let's use the system google-perftools if available:
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:
if check $USE_SYSTEM_PERFTOOLS /usr/include/google/malloc_hook.h "google-perftools" ; then
    cd $PATH_TO_SOURCES/libraries/i686-linux
    rm -f lib_release_client/libtcmalloc.* lib_release_client/libstacktrace.*
    rm -rf include/google/
    cp -a /usr/lib/libstacktrace.* /usr/lib/libtcmalloc.so* lib_release_client/
    cp -a /usr/include/google include/
    update_manifest tcmalloc
    update_manifest stacktrace
fi


# Let's use the system libstdc++ if available:
* [[User:Henri Beauchamp/Automated Linux Build Script (1.20 and earlier)]]
if check $USE_SYSTEM_UUID /usr/lib/libstdc++.so.6 "libstdc++" ; then
* [[User:Henri Beauchamp/Building the viewer with CMake/cmake-SL script]]
    rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libstdc++.*
    update_manifest libstdc
fi


# Force libkdu inclusion
* Please also see the (user contributed) instructions at [[User:Michelle2_Zenovka/cmake]]
# (disabled for now (v1.21.0 viewer) as the cmake scripts fail to get libkdu from Internet).
if false; then
# Remove everything dealing with libstdc++ and the crash logger:
update_manifest libstdc
update_manifest 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/#        them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_DIR/viewer_manifest.py
sed -e "s/^#  /  /" $TEMP_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
rm -f $TEMP_DIR/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
fi


# Check to see if we simply want to unpack the sources:
=== FreeBSD ===
if [ "$1" == "--prep" ] ; then
    echo "Prepared sources available in: $PATH_TO_SOURCES"
    exit 0
fi


compile
A list of patches is given for [[Compiling the viewer (FreeBSD)]]. They are obsolete, and no longer work.
</nowiki>
</pre>
</code>
<br />
<br />
 
== 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|submitting patches]].


[[Category:Compiling viewer]]
[[Category:Compiling viewer]]
[[Category:Articles_in_need_of_updating]]

Latest revision as of 16:55, 5 February 2021

KBcaution.png Note Linden Lab no longer actively maintains Linux viewer third party dependencies. You may run into issues building the viewer on modern distros.
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.

  • hg [package: mercurial]
  • 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
  • Linden Lab has backported gcc-4.6.3 to Debian Squeeze; this port and its associated libraries are used when building the official Linux viewer.
The sources and Debian packages for this backport are available from Debian GCC Backport
  • 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.)
KBtip2.png Tip: To boost your productivity as a developer, try the suggestions at Development Environment for Multiple Viewers about directory structure, multiple viewers and automation of repetitive tasks.


What does 'Standalone' mean?

The current sources no longer use the term "standalone"; it has been replaced by "usesystemlibs".

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

The source for the official Viewer's 2.x codebase resides in mercurial repositories hosted on http://bitbucket.org/lindenlab (a.k.a. http://bitbucket.org/lindenlab).

KBnote.png Old Versions Find instructions on how to obtain the sources for official 1.x codebase as well as Snowglobe 1.x and 2.x on the archived version of this section.

To check out the lindenlab/viewer-release branch, do 

hg clone http://bitbucket.org/lindenlab/viewer-release

This will create a new folder called viewer-release inside your current working directory, containing the source tree. (You can optionally specify a different target directory. See hg help clone.) Other long-lived branches of interest are lindenlab/viewer-beta and lindenlab/viewer-development. Contributions should usually be based on viewer-development.

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
libidn.so libidn11-dev libidn11-devel

shortcut commands for the above

Debian/Ubuntu: 

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

Fedora/Red Hat: 

sudo yum install glibc-devel libstdc++-devel libX11-devel mesa-libGL-devel libXrender-devel libidn11-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 openSUSE
libopenal.so libopenal-dev openal-soft-devel openal-soft-devel
libvorbis.so
libvorbisenc.so
libvorbisfile.so 		libvorbis-dev libvorbis-devel libvorbis-devel
libalut.so libalut-dev freealut-devel freealut-devel
libapr-1.so libapr1-dev apr-devel libapr1-devel
libaprutil-1.so libaprutil1-dev apr-util-devel libapr-util1-devel
libboost_program_options.so
libboost_regex.so
libboost_signals.so 		libboost-dev boost-devel boost-devel
libcares.so libc-ares-dev c-ares-devel libcares-devel
libxmlrpc-epi.so libxmlrpc-epi-dev ? libxmlrpc-epi0-devel
libopenjpeg.so libopenjpeg-dev openjpeg-devel openjpeg-devel
libjpeg.so libjpeg62-dev (libjpeg-dev) libjpeg-devel libjpeg62-devel
libSDL.so libsdl1.2-dev SDL-devel libSDL-devel
libgstreamer-0.10.so libgstreamer0.10-dev gstreamer-devel gstreamer-0_10-devel
gstreamer-0.10 plugins libgstreamer-plugins-base0.10-dev gstreamer-plugins-base-devel gstreamer-0_10-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

openSUSE:

You will have to add the buildservice repository home:lemmy04:snowglobe (http://download.opensuse.org/repositories/home:/lemmy04:/snowglobe/) to your package sources. 

sudo zypper install openal-soft-devel libvorbis-devel freealut-devel libapr1-devel libapr-util1-devel \
  boost-devel libcares-devel libxmlrpc-epi0-devel openjpeg-devel libjpeg62-devel libSDL-devel gstreamer-0_10-devel gstreamer-0_10-plugins-base-devel

More problematic libraries (standalone)

Easy so far, now here's where the trouble starts. Not all required packages are in debian, not to mention you might not even be using debian of course; but we (standalone builders) rely for the most part on the tremendous work done by 64-bit pioneer User:Robin_Cornelius who happens to use debian. Although many required packages are now in debian, some still need to be downloaded from Robin's private repository (assuming you're on debian). TODO: Add instructions for those not using ubuntu/debian.

Edit your /etc/apt/sources.list and add the following lines: 

# Repository for SecondLife.
deb http://apt.byteme.org.uk squeeze main
deb-src http://apt.byteme.org.uk squeeze main

or 

# Repository for SecondLife.
deb http://apt.byteme.org.uk lenny main
deb-src http://apt.byteme.org.uk lenny main

depending on whether you are using testing (squeeze) or stable (lenny). Note that you won't be able to compile Snowglobe 2.x on lenny because the Qt library is too old.

Run apt-get update to get the Package files from byteme as usual. You can ignore the warning about the missing public key, or do what is described at the bottom of this page under 'GPG Keys and Signed repository' (note the remark about not using root), thus: 

% gpg --keyserver hkp://keyserver.ubuntu.com --recv-key 0x729A79A23B7EE764
% gpg --export 0x729A79A23B7EE764 | sudo apt-key add -

or for ubuntu users we use the openmetaverse repo, run this command to add the repo: 

# Openmetaverse repo
sudo add-apt-repository ppa:openmetaverse/ppa

NOTE: If you are on Ubuntu 12.04 ("Precise") you will also need to edit the file /etc/apt/sources.list.d/openmetaverse-ppa-precise.list so that it refers to the "lucid" distro instead of "precise" because the maintainers haven't made packages for "precise" yet.

Change /etc/apt/source.list.d/openmetaverse-ppa-precise.list from: 

deb http://ppa.launchpad.net/openmetaverse/ppa/ubuntu precise main
deb-src http://ppa.launchpad.net/openmetaverse/ppa/ubuntu precise main

To be: 

deb http://ppa.launchpad.net/openmetaverse/ppa/ubuntu lucid main
deb-src http://ppa.launchpad.net/openmetaverse/ppa/ubuntu lucid main

and of course to add the keys (only on Debian) 

gpg --keyserver hkp://keyserver.ubuntu.com --recv-key 0x50A40F50
gpg --export 0x50A40F50 | sudo apt-key add -

and always remember to update after adding repos 

apt-get update

Finally install these packages:

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)


Shortcut commands for the above 

sudo apt-get install libcurl4-cares-dev libllqtwebkit2-dev glh-linear boost-coroutine libndofdev-dev

If you are on lenny you will also (automatically) install the packages cmake, libopenjpeg-dev and libopenjpeg2 from byteme. This is because the packages in lenny contain bugs.

The libjsoncpp-dev installs a library called /usr/lib/libjson.so, but the viewer is looking for one called libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so in '/usr/lib' and '/usr/local/lib'. Therefore execute the following command as root: 

# This is not needed on Snowglobe 1.4.1 and higher.
% ln -s /usr/lib/libjson.so /usr/local/lib/libjson_linux-gcc-$(g++ -dumpversion)_libmt.so

In order to run the tests, you need a template library called 'tut'. Because this is a template library, we can just use the library archive from Linden Lab for any architecture. Therefore, to install tut, run: 

% scripts/install.py tut

Until recently for some completely mysterious reason, the source code includes <tut/tut.hpp> while configure checks for tut.h in /usr/lib and /usr/local/lib only (CXXFLAGS? Never heard of that). In order to fix this brokenness for non-Snowglobe viewers or based on older snowglobe versions (prior to 1.4, or 2.1), execute the following (2.x viewers older than 2.1 and 1.x viewers older than 1.4 only): 

# This is not needed on Snowglobe 1.4.1 and higher.
% sudo touch /usr/local/include/tut.h

which satisfies the configure check. The installed tut.hpp is still used anyway since libraries/include is in the include search path by default. Alternatively, edit indra/cmake/Tut.cmake and comment out these two lines: 

 #include(FindTut)
 #include_directories(${TUT_INCLUDE_DIR})

Oh WAIT! On 2.0 standalone libraries/include is NOT included anymore, and it seems impossible to fix the cmake spaghetti so here's what you have to do on top of the above: 

sudo cp -r libraries/include/tut /usr/local/include

Sorry but there is no other way.

However, if you are using snowglobe 1.4 or a later 1.x, or snowglobe 2.1 or later, or a viewer based on those, then the viewer actually looks for tut/tut.hpp. So, you can still install it in /usr/local/include/tut/, but you can also install it in -say- /somewhere/include/tut/ and set the environment variable CMAKE_INCLUDE_PATH (a colon separated list of paths) to include /somewhere/include before configuration. Note that due to a cmake problem/bug it will find /somewhere/include but still use the include path of any other library, including /usr/include or /usr/local/include, so make sure you remove any other tut installation from common paths if you use the latter method.

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 slvoice
KBnote.png Note: In earlier revisions, the package was named vivox rather than slvoice.

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

Needs to be redone - Oz Linden

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)

Build the viewer with autobuild

Configuring and building with autobuild works the same on all platforms. Full instructions may be found at Build_Viewer_With_Autobuild.

KBcaution.png Important: If you are using prepackaged 3rd party libraries from Linden (not a stand alone build) then you will need to build using gcc version 4.1; set CC and CXX accordingly. TODO: expand/update

Configuration notes

  • To build for 'standalone' (see `What does 'standalone' mean?` above) choose an OpenSourceStandAlone option.
  • If you want to use KDevelop add -G KDevelop3.
  • 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.
  • OpenSource configurations do not install FMOD (which will be disabled).
  • The environment variables CC and CXX are picked up automatically as usual. However, this is not the case of CXXFLAGS and LDFLAGS. 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.
  • 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.
  • 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 restart the configuration process from scratch without any cached values affecting the configuration, erase the CMakeCache.txt in the build directory.
  • Autobuild appears to bind the CXX and CC env. variables at configuration time. So the following should work if done once:
    • CXX=g++-4.1 CC=gcc-4.1 autobuild configure -c Release

Where's the built viewer?

On Linux, your build will be at 

build-linux-ARCH/newview/packaged

where "ARCH" should be something like "i686" or "x86_64" (depending on your platform).

KBcaution.png Important: Currently, the build dir will be build-linux-i686, even when a 64-bit build was requested by autobuild configure [...] -- -DWORD_SIZE=64 [...]. See OPEN-106.

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!)
  • If you are building on openSUSE 11.2 or newer, and your builds fail with lots of "undefined reference to ..." message: set the environment variable SUSE_ASNEEDED to 0 before building.

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.

KBcaution.png 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.


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). They are obsolete, and no longer work.

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