|
|
| (194 intermediate revisions by 15 users not shown) |
| Line 1: |
Line 1: |
| {{multi-lang}} | | {{Multi-lang}} |
| {{CompileNav}} | | {{CompileNav}} |
| | {{TOC}} |
|
| |
|
| 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]].
| | ==Step 0. Review BUILD.LINUX.md== |
| <onlyinclude>
| | There is a [https://github.com/secondlife/viewer/blob/develop-linux/doc/BUILD.LINUX.md BUILD.LINUX.md] markdown file in the active '''develop-linux''' branch (see '''Step 2''') which will eventually become the primary documentation for building the SL viewer on Linux. In the meantime the instructions below may also be helpful. |
| == Required tools ==
| |
| There are a number of tools that need to be installed first.
| |
|
| |
|
| * '''cmake''' [package: cmake]
| | ==Step 1. Install Requirements== |
| * <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 was suggested as the best choice
| |
| ** 2.6 seems to be fine as well
| |
| ** python 2.3 or before doesn't work in SL development
| |
| ** python 2.5 or later works, but it is (''was?'') not recommended, since it generates a lot of warning messages when running develop.py (''still true as of Snowglobe2?'')
| |
| * <b>g++</b> [package: g++]
| |
| ** Note: gcc 4.4 (which is in recent Ubuntu and debian) won't work in versions prior to 2.0 (or Snowglobe 1.3), 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)
| |
|
| |
|
| The build process may use the following optional tool:
| | * Python 3.7+ |
| | * [https://git-scm.com/downloads Git] |
| | * [https://cmake.org/download/ CMake] 3.20+ (need to be able to handle <code>--config</code> option) |
| | * Native packages and tools (this list may be incomplete, please update as new dependencies are discovered): |
| | libfontconfig-dev libglib2.0-dev libglvnd-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libosmesa6-dev libvlc-dev libwayland-dev libx11-dev ninja-build python3-venv |
| | * [[Autobuild]] (probably best installed in a [https://docs.python.org/3/library/venv.html virtual environment]) |
|
| |
|
| * <b>distcc</b> distributed compiler (useful if you have multiple PCs.)
| | ===Intermediate Check=== |
| </onlyinclude>
| |
|
| |
|
| == Unpack the source tree ==
| | Confirm things are installed properly so far by typing the following in a terminal: |
| | cmake --version |
| | python3 --version |
| | git --version |
| | autobuild --version |
|
| |
|
| You can get the source either from the source archives available at [[Source downloads]], or you can get it from [[Subversion]].
| | If everything reported sensible values and not "Command not found" errors, then you are in good shape! |
|
| |
|
| Using a source archive is the easier option for getting started, and is strongly recommended especially for the first-time builders. However, some says that if you plan to do active development and want to make your own modifications, while merging Linden Lab's changes, Subversion will probably be much more convenient on the long term.
| | ==Step 2. Checkout Code== |
|
| |
|
| === Getting the source from the source archives === | | ===Viewer=== |
| Get the source from [[Source downloads]]. You will need all 3 archives: source, artwork and libraries (however, if you are compiling snowglobe (or any other version using 'easybuild') then you already have the source, and you do not need to get the libraries because they will be downloaded automatically. You still need to get (the latest) artwork though).
| |
|
| |
|
| Choose a location and unpack the source tree and the art work. They will be extracted into a
| | Open a terminal and checkout the viewer source code: |
| directory called <b>linden</b>.
| | git clone https://github.com/secondlife/viewer.git |
|
| |
|
| <code>
| | Until it is merged into the '''develop''' branch you need to checkout '''develop-linux''': |
| % tar -xzf slviewer-src-<version>.tar.gz
| | cd viewer |
| or % tar -xzf snowglobe-src-viewer-<version>.tar.gz | | git checkout develop-linux |
| % tar -xzf slviewer-linux-libs-<version>.tar.gz | |
| % unzip slviewer-artwork-<version>.zip
| |
| </code>
| |
|
| |
|
| === Getting the source from Subversion === | | ===Build Variables=== |
| Select a source [[Source branches|branch]] to check out.
| |
|
| |
|
| Check it out with:
| | See [[Building the Viewer with Autobuild#Select Build Variables]] |
| <code>
| |
| % svn checkout <nowiki>http://svn.secondlife.com/svn/linden/</nowiki>''<branch>'' ''<directory>''
| |
| </code>
| |
| If you don't specify the directory, it'll use the last part of the branch path by 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. Note that [[Snowglobe]] (or any version using 'easybuild') automatically downloads the libraries, you will only need to get the artwork.
| | ==Step 3. Configure== |
|
| |
|
| 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:
| | Be sure you have the following environment variables set before continuing: |
| <code>
| |
| % ln -sf ''<directory>'' linden
| |
| </code>
| |
|
| |
|
| Now unpack the libraries and artwork:
| | AUTOBUILD_ADDRSIZE=64 |
| <code>
| | AUTOBUILD_VARIABLES_FILE=<path to autobuild viewer variables> |
| % tar -xzf slviewer-<os>-libs-<version>.tar.gz | |
| % unzip slviewer-artwork-<version>.zip | |
| </code> | |
|
| |
|
| <br />
| | Configuring and building with '''autobuild''' works the same on all platforms. Full instructions may be found at [[Build_Viewer_With_Autobuild]]. |
|
| |
|
| == Installing the required libraries (that Linden Lab can not or does not provide)==
| | autobuild configure -c RelWithDebInfoOS |
|
| |
|
| === Libraries and header files that usually come with a Linux distribution === | | ==Step 4. Build== |
| Make sure the libraries and header files for the following packages are installed on your system:
| |
| {|border="1" cellpadding="5" cellspacing="0"
| |
| |-
| |
| !Package
| |
| !Ubuntu
| |
| !Fedora/Red Hat
| |
| |-
| |
| !GL
| |
| |mesa-common-dev
| |
| |mesa-libGL-devel
| |
| |-
| |
| !GLU
| |
| |libglu1-mesa-dev
| |
| |mesa-libGLU-devel
| |
| |-
| |
| !glibc
| |
| |libc6-dev
| |
| |glibc-devel
| |
| |-
| |
| !stdc++ library
| |
| |libstdc++6
| |
| |libstdc++-devel
| |
| |-
| |
| !X11
| |
| |libx11-dev
| |
| |libX11-devel
| |
| |-
| |
| !zlib
| |
| |zlib1g-dev
| |
| |zlib-devel
| |
| |-
| |
| !openssl
| |
| |libssl-dev
| |
| |openssl-devel
| |
| |-
| |
| !xrender (for viewer 2.0)
| |
| |libxrender-dev
| |
| |?
| |
| |}
| |
|
| |
|
| ==== shortcut commands for the above ====
| | autobuild build |
|
| |
|
| Ubuntu:
| | ===Running your newly built viewer=== |
|
| |
|
| sudo apt-get install mesa-common-dev libglu1-mesa-dev libc6-dev libstdc++6 libx11-dev zlib1g-dev libssl-dev libxrender-dev
| | ==Step 5. Run== |
|
| |
|
| Fedora:
| | To launch the '''viewer''' you built, from your source tree root directory, run: |
|
| |
|
| sudo yum install mesa-libGL-devel mesa-libGLU-devel glibc-devel libstdc++-devel libX11-devel zlib-devel openssl-devel
| | build-linux-x86_64/newview/packaged/secondlife |
|
| |
|
| === FMOD (audio) === | | ==Step 6. Optional== |
| FMOD is an audio output library. FMOD is required to make SL viewer to generates sounds.
| |
|
| |
|
| * Fetch and unpack <b>FMOD 3.75</b> <http://www.fmod.org/> (Use URL below) into a directory that is a peer of your working (linden) directory
| | ===Running Unit Tests=== |
| * Note: in trunk code (march 2009) there is no need to manually create the three linden/libraries/i686-linux/... directories
| |
|
| |
|
| wget -c http://www.fmod.org/files/fmod3/fmodapi375linux.tar.gz
| | TODO: provide instructions for running unit tests. |
| tar -xzvf fmodapi375linux.tar.gz
| |
| mkdir -p linden/libraries/i686-linux/lib_release_client/
| |
| mkdir -p linden/libraries/i686-linux/lib_debug/
| |
| mkdir -p linden/libraries/i686-linux/lib_release/
| |
| cd fmodapi375linux/
| |
| cp api/inc/* ../linden/libraries/i686-linux/include/
| |
| cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
| |
| cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release/
| |
| cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_debug/
| |
|
| |
|
| * FMOD is available free of charge, but it is not itself an open-source. We understand that some Linux users dislike to use software whose source is not open, and FMOD falls into this category. <b>If</b> you wish to avoid FMOD, thus disabling audio, you may make these changes:
| | ===Optional: Installing Proprietary Libraries=== |
| ** Comment-out the libfmod line in indra/newview/viewer_manifest.py
| |
|
| |
|
| == Installing the required dependencies (prepackaged by Linden Lab)==
| | Some builds of the the Viewer depends on proprietary libraries (alternative open source libraries are also provided for developers who prefer or are not licensed to use the proprietary libraries). Lindens do not distribute these libraries, so you will need to fetch and install these even if you download the libraries packages. (This is due to licensing restrictions. Don't ask, Lindens already did, and can't get permission. So you do have to get them yourself.) |
|
| |
|
| The Second Life Viewer has a number of compile/link dependencies on external libraries which
| | TODO: provide instructions for building proprietary libraries. |
| 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.
| | ==Handling Problems== |
| <code>
| |
| tar xvfz slviewer-linux-libs-<version>.tar.gz
| |
| </code>
| |
|
| |
|
| '''Note''': as of 1.21, very little of what once was included in the libraries tarball are still there, so this is a very small tarball. The other libraries will be downloaded as part of the build process.
| | If you encounter errors or run into problems following the instructions above, please first check whether someone else already had the same issue. A solution might be known already. |
|
| |
|
| If you don't wish to use the precompiled libraries, see [[Building the viewer libraries (Linux)]]. | | You may find the solution in any of these resources: |
| | * [[{{TALKPAGENAME}}|This talk page]] (Report useful experiences there) |
| | * [[#Common_Issues.2FBugs.2FGlitches_And_Solutions|Issue list below]] (If new issues, please add it to talk page above instead of there) |
| | * [[Talk:Microsoft_Windows_Builds|Old talk page]] |
| | * [[Common compilation problems]] (Rather old) |
| | * [[Issue tracker]] |
|
| |
|
| == Compiling with CMake ==
| | * Fix it: [[Modifying CMake Files]] and please, submit a patch! |
|
| |
|
| 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.
| | ===Getting Help=== |
|
| |
|
| '''NOTE:''' These instructions are for the viewer versions 1.21 and beyond. For older viewers (1.20 and earlier) see [[Compiling the viewer with SCons (Linux)]]
| | Even when no description of your problem has been written down yet, someone might know about it, so get in touch with the community to get help. |
|
| |
|
| === Configuring your tree ===
| | * Subscribe to [[OpenSource-Dev|OpenSource-Dev Mailing List]] ([https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev subscribe]) and post your question there. |
| 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 indra subdirectory''' and run one of the following commands:
| |
| ** make: <code>"./develop.py"</code>
| |
| ** KDevelop: <code>"./develop.py -G KDevelop3"</code>
| |
| | |
| '''NOTE:''' The above commands will configure a "non-standalone" version of the source code tree. This means that the required third party library packages (as built by Linden Lab) will be downloaded during the CMake process.
| |
| | |
| === Starting the build ===
| |
| | |
| To start a build, do one of the following:
| |
| | |
| # Run "./develop.py build"
| |
| | |
| -- 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 distcc ===
| |
| | |
| If you have multiple PCs, you can speed up the build process by using distcc.
| |
| | |
| 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="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="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 appropriate number to <code>-j</code> option.
| |
| | |
| = Prebuilt libraries vs. standalone builds =
| |
| | |
| While many users will want to use the prebuilt libraries that we provide, we're also interested in making life as easy as possible for packagers who want to use their platform's native libraries.
| |
| | |
| If you run <code>ccmake</code>, you should see a <code>STANDALONE</code> option that determines whether the build will use your system's libraries or our prepackaged ones. Flipping this to <code>ON</code> should be all you need to do to perform a packager-friendly build.
| |
| | |
| For standalone builds, we'd really like to beef up the checks for system libraries so that for example <code>cmake</code> will fail if a required library (such as OpenJPEG) isn't installed. We welcome all patches that help out with this.
| |
| | |
| * [[Building_the_viewer_with_CMake/cmake-SL_script|cmake-SL]]: a script for standalone, pre-built and mixed libraries viewer builds under Linux.
| |
| * [[Talk:CMake#Issues_when_compiling_a_standalone_Linux_viewer|Problems when compiling a standalone Linux viewer]]
| |
| | |
| | |
| == 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 [[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.
| |
| | |
| * 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'
| |
| ** <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.
| |
| | |
| * Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:
| |
| <code>
| |
| $ ( cd newview && LD_LIBRARY_PATH="`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 />
| |
| ==== 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 <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.
| |
| | |
| 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:
| |
| <code>
| |
| cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
| |
| mkdir "$SLSRC/indra/lib"
| |
| cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"
| |
| </code>
| |
| | |
| The file <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.
| |
| | |
| ==== 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:
| |
| <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.
| |
| | |
| 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 '<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>
| |
| | |
| The file which controls what (and where) files go into the end-user runtime viewer directory is <b>indra/newview/viewer_manifest.py</b>
| |
| | |
| | |
| == 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:
| |
| | |
| * [[User:Henri Beauchamp/Automated Linux Build Script (1.20 and earlier)]]
| |
| * [[User:Henri Beauchamp/Building the viewer with CMake/cmake-SL script]]
| |
| | |
| === FreeBSD ===
| |
| | |
| A list of patches is given for [[Compiling the viewer (FreeBSD)]].
| |
| | |
| = What to do if it doesn't work for you =
| |
| | |
| * Ask for help on [[IRC]] (irc.efnet.org #opensl)
| |
| * Find someone on the [[SLDev|SLDev mailing list]]
| |
| * Fix it: [[Modifying CMake Files]] (and please, submit a patch!)
| |
| | |
| Please also see the (user contributed) instructions at [[User:Michelle2_Zenovka/cmake]]
| |
| | |
| = 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]] |
Step 0. Review BUILD.LINUX.md
There is a BUILD.LINUX.md markdown file in the active develop-linux branch (see Step 2) which will eventually become the primary documentation for building the SL viewer on Linux. In the meantime the instructions below may also be helpful.
Step 1. Install Requirements
- Python 3.7+
- Git
- CMake 3.20+ (need to be able to handle
--config option)
- Native packages and tools (this list may be incomplete, please update as new dependencies are discovered):
libfontconfig-dev libglib2.0-dev libglvnd-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libosmesa6-dev libvlc-dev libwayland-dev libx11-dev ninja-build python3-venv
Intermediate Check
Confirm things are installed properly so far by typing the following in a terminal:
cmake --version
python3 --version
git --version
autobuild --version
If everything reported sensible values and not "Command not found" errors, then you are in good shape!
Step 2. Checkout Code
Viewer
Open a terminal and checkout the viewer source code:
git clone https://github.com/secondlife/viewer.git
Until it is merged into the develop branch you need to checkout develop-linux:
cd viewer
git checkout develop-linux
Build Variables
See Building the Viewer with Autobuild#Select Build Variables
Step 3. Configure
Be sure you have the following environment variables set before continuing:
AUTOBUILD_ADDRSIZE=64
AUTOBUILD_VARIABLES_FILE=<path to autobuild viewer variables>
Configuring and building with autobuild works the same on all platforms. Full instructions may be found at Build_Viewer_With_Autobuild.
autobuild configure -c RelWithDebInfoOS
Step 4. Build
autobuild build
Running your newly built viewer
Step 5. Run
To launch the viewer you built, from your source tree root directory, run:
build-linux-x86_64/newview/packaged/secondlife
Step 6. Optional
Running Unit Tests
TODO: provide instructions for running unit tests.
Optional: Installing Proprietary Libraries
Some builds of the the Viewer depends on proprietary libraries (alternative open source libraries are also provided for developers who prefer or are not licensed to use the proprietary libraries). Lindens do not distribute these libraries, so you will need to fetch and install these even if you download the libraries packages. (This is due to licensing restrictions. Don't ask, Lindens already did, and can't get permission. So you do have to get them yourself.)
TODO: provide instructions for building proprietary libraries.
Handling Problems
If you encounter errors or run into problems following the instructions above, please first check whether someone else already had the same issue. A solution might be known already.
You may find the solution in any of these resources:
Getting Help
Even when no description of your problem has been written down yet, someone might know about it, so get in touch with the community to get help.