Difference between revisions of "User:Opensource Obscure/Compiling the viewer (Linux)"

From Second Life Wiki
Jump to navigation Jump to search
(Created page with '{{multi-lang}} {{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 debi...')
 
m (to be deleted as not needed)
Line 1: Line 1:
{{multi-lang}}
Cancellata, era un clone di [[Compiling_the_viewer_(Linux)]]. --[[User:Opensource Obscure|oobscure]] 14:58, 8 April 2011 (PDT)
{{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]].
<onlyinclude>
== Required tools ==
There are a number of tools that need to be installed first.
 
* '''cmake''' [package: cmake]
** Currently (snowglobe 1.3.2 and higher) cmake 2.6.2 is the minimum required version.
* <b>yacc</b> or compatible tool [suggested package: bison]
* <b>lex</b> or compatible tool [suggested package: flex]
* <b>python</b> [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 [[issue tracker|report]] them.
** python 3.x hasn't been tested yet.
* <b>g++</b> [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 <b>GCC 4.3</b> and to run 'export CXX=/usr/bin/g++-4.3' or whatever your binary is before trying to compile. Another workaround is to use update-alternatives; for example, if you already have 4.4 installed, try this:
sudo apt-get install g++-4.3
sudo update-alternatives --remove-all gcc
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.3 43  --slave /usr/bin/g++ g++ /usr/bin/g++-4.3  --slave /usr/bin/gcov gcov /usr/bin/gcov-4.3
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.4 44  --slave /usr/bin/g++ g++ /usr/bin/g++-4.4  --slave /usr/bin/gcov gcov /usr/bin/gcov-4.4
then choose 4.3:
sudo update-alternatives --config gcc
* '''libboost-program-options-dev''' was needed on Ubuntu 8.04 to use cmake, but it's '''not needed anymore''' to build a 1.23-render-pipeline on Ubuntu 9.04-beta (nor Snowglobe 2 on Ubuntu 9.10)
* '''make''' (package: make)
* '''bzip2''' (package: bzip2)
 
The build process may use the following optional tools:
 
* <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>[[Development Environment for Multiple Viewers]]</b> Boost your productivity as developer; directory structure, multiple viewers, automation of repetitive tasks.
 
</onlyinclude>
 
== Getting the source ==
 
Releases and release candidates are available as source archives (zip or tar) from [[Source downloads]],
or you can get the latest (experimental) sources with [[Subversion]].
 
Using a source archive is safer and strongly recommended for first-time builders.
However, if you plan to do active development and want to make your own modifications, while merging Linden Lab's changes,
or if you want to live on the bleeding edge, then Subversion should be your choice.
 
=== Using the source archives ===
Get the source from [[Source downloads]]. The source is extracted into a directory called <tt>linden</tt>.
 
For example,
<code>
% tar xzf snowglobe-src-viewer-<version>.tar.gz
</code>
 
=== Using subversion ===
Select a source [[Source branches|branch]] to check out.
 
Check it out with:
<code>
% svn checkout <nowiki>http://svn.secondlife.com/svn/linden/</nowiki>''<branch>'' '''target-directory'''
</code>
If you don't specify the directory, it'll use the last part of the branch path by default.
 
See also [[Version control repository]].
 
 
 
== Installing the required libraries (that Linden Lab can not or does not provide)==
 
=== Libraries and header files that usually come with a Linux distribution ===
Make sure the libraries and header files for the following packages are installed on your system:
{|border="1" cellpadding="5" cellspacing="0"
|-
!Library
!Debian/Ubuntu
!Fedora/Red Hat
|-
!libc.so
|libc6-dev
|glibc-devel
|-
!libstdc++.so.6
|libstdc++6
|libstdc++-devel
|-
!libX11.so
|libx11-dev
|libX11-devel
|-
!libGL.so
|nvidia-glx-dev '''or''' libgl1-mesa-dev
|mesa-libGL-devel
|-
!libXrender.so
|libxrender-dev
|libXrender-devel
|}
 
==== shortcut commands for the above ====
 
Debian/Ubuntu:
 
sudo apt-get install libc6-dev libstdc++6 libx11-dev libxrender-dev [libgl1-mesa-dev|nvidia-current-dev|...]
 
Fedora/Red Hat:
 
sudo yum install glibc-devel libstdc++-devel libX11-devel mesa-libGL-devel libXrender-devel
 
=== Recommended libraries and headers ===
 
Not really required but you should probably install them. FIX ME: REALLY? WHY?
 
{|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
|}
 
==== shortcut commands for the above (2) ====
 
Debian/Ubuntu:
 
<pre><nowiki>
sudo apt-get install libglu1-mesa-dev zlib1g-dev libssl-dev libogg-dev libpng12-dev libdbus-glib-1-dev libgtk2.0-dev
</nowiki></pre>
 
Fedora/Red Hat:
 
<pre><nowiki>
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>
 
 
== Installing the Non-Free Shared Libraries and the Artwork Packages ==
 
{{KBtip|With Snowglobe, and as of Viewer 2.0, this step can be performed by running:
: <code> % scripts/public_fetch_tarballs.py</code>}}
 
Some of the artwork and libraries used by the viewer are provided by Linden Lab as two tarballs. You can get these files from the [[Source downloads]] page, and unpack them manually over the source tree. You can also find URLs for the specific version of these files needed by your source version in <tt>doc/asset_urls.txt</tt>.
 
 
=== slviewer-linux-libs-<version>.tar.gz ===
'''This file is optional.''' It contains non-free fonts and the KDU shared library. Obviously, you can also skip it if you are building ''standalone''.
 
If you download the libs to the top folder, where the <tt>linden</tt> folder is after getting and extracting the viewer source code tarball, the following command should unpack everything to the right spot:
: <code> % tar xvfz slviewer-linux-libs-<version>.tar.gz</code>
 
=== slviewer-artwork-<version>.zip ===
This file contains artwork and various assets and is '''required''' in order to run the viewer, or build a package target. It needs to be unzipped over the source tree:
: <code> % unzip slviewer-artwork-oss-viewer-<version>.zip</code>
 
== Compiling ==
 
This page describes how to build the Second Life viewer with [[CMake]]. CMake is a system for generating per-platform build files.  On Linux, it will generate your choice of Makefiles or KDevelop project files.
 
 
=== Configuring your tree ===
Before you first run a build, you'll need to configure things.  There's a <code>develop.py</code> script that will create a reasonably sane default configuration for you.
 
From the command line, cd into the <code>indra</code> subdirectory,
% cd indra
Next you can configure the project by running,
% ./develop.py [-m64|-m32] [--standalone] [--type=Debug] configure [-D...]
Note that <code>-m32</code> is the default even on 64bit. In order to build for 64-bit you must specify <code>-m64 --standalone</code>. Any cmake defines (starting with -D, see the notes directly below) must be specified ''after'' (to the right of) the 'configure' keyword.
 
'''Note:''' To build for 'standalone' (see `[[#What_does_.27Standalone.27_mean.3F|What does 'standalone' mean?]]` above) add <code>--standalone</code> to the configure commandline.
 
'''Note:''' If you want to use KDevelop add <code>-G KDevelop3</code> to the configure commandline.
 
'''Note:''' Configuring a "non-standalone" version of the source code tree will cause the required (32-bit) third party library packages (as built by Linden Lab) to be downloaded during the CMake build process.
 
'''Note:''' The environment variables CC and CXX are picked up automatically as usual. However, this is not the case of CXXFLAGS and LDFLAGS. If you are compiling [[Snowglobe]] then you can pass the following to the configure commandline: <code>-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" -DCMAKE_EXE_LINKER_FLAGS:STRING="$LDFLAGS"</code> to enable the use of these environment variables.
 
'''Note:''' You can make the build process more verbose (make it print the compiler commands it executes) by passing <code>-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON</code> as well.
 
'''Note:''' For debugging purposes you can build without optimization and with debugging symbols by specifying <code>--type=Debug</code>.
 
'''Note:''' 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).
 
If you want to redo this step, erase the <code>CMakeCache.txt</code> file in the build directory and rerun develop.py.
 
=== Starting the build ===
 
To start a build, do one of the following:
 
#  Use the '''same command''' that you used to configure (but minus the -D... options), but replace 'configure' with 'build'.
For example: <code>./develop.py -m64 --standalone --type=Debug build</code>
 
-- or --
 
#  Find your build directory and change to it
#:  In the CMake world, we keep source and object files separate.  The <code>develop.py</code> script will create and populate a build directory for you.  On Linux, this will be named <code>viewer-linux-ARCH-BUILD</code> (where "ARCH" is "i686" or "x86_64", and "BUILD" varies on debug level)
#  Build with your preferred build tool
## Type <code>make</code>
##: -- or---
## Load it into KDevelop
 
=== Where's the built viewer? ===
 
On Linux, your build will be here:
<pre>
viewer-linux-ARCH-BUILD/newview/packaged
</pre>
 
...where "''ARCH''" is something like "i686" or "x86_64" (depending on your platform), and "''BUILD''" depends on which debug level you chose.
 
=== Using ccache ===
 
It is very highly recommended that you use and install [http://ccache.samba.org/manual.html 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 <code>/usr/local/bin</code>. Make sure that <code>/usr/local/bin</code> comes first in your <code>PATH</code>,
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),
 
<code>
% apt-get install ccache
% cd /usr/local/bin
% ln -s ../../bin/ccache gcc
% ln -s ../../bin/ccache g++
</code>
 
And then to test, as normal user (make sure you are not in /usr/local/bin anymore),
 
<code>
% which g++
</code>
 
This should print <code>/usr/local/bin/g++</code>, if not fix you <code>PATH</code>.
 
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.
 
=== 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 <code>CXX</code> environment variable, by adding ccache to them.
 
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.,
 
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 <code>g++</code>, 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 <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 you invoke <code>make</code> command by yourself, don't forget to add the <code>-j</code> 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|opensource-dev mailing list]]
* Fix it: [[Modifying CMake Files‎]] (and please, submit a patch!)
 
= Submitting Patches =
This is probably far down the road, but if you make changes to the source and want to submit them, see the page about [[Submitting patches|submitting patches]].
 
 
 
[[Category:Compiling viewer]]

Revision as of 13:58, 8 April 2011

Cancellata, era un clone di Compiling_the_viewer_(Linux). --oobscure 14:58, 8 April 2011 (PDT)

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Opensource_Obscure/Compiling_the_viewer_(Linux)&oldid=1139748"