	Important! 현재 한글화 진행중
	현재 한글화 진행중인 문서입니다. 스노우 글로브 2.0에 대한 사항은 추가 해야할지도 모르겐군요.

Second Life viwer를 리눅스에서 빌드하는 방법에 대해서 설명합니다. 빌드를 위해서 사용하는 리눅스 배포판의 종류는 debian 와 debian 기반의 시스템인 ubuntu,그리고 Fedora 입니다. 다른 운영체제에서 빌드 하기 위해서는 Get source and compile을 참고 바랍니다.

필요한 도구

다음은 빌드를 위해서 우선적으로 설치되어야하는 도구 목록입니다

cmake [패키지: cmake]
yacc 또는 호환 도구 [관련 패키지: bison]
lex 또는 호환 도구 [관련 패키지: flex]
python [패키지: python]
- python 2.4 를 설치하는 것을 추천합니다.
- python 2.6 도 괜찬씁니다.
- python 2.3 또는 이전 버젼은 지원하지 않습니다.
- python 2.5 버젼의 경우 현재 develop.py을 실행시 많은 오류 메시지가 발생합니다. (still true as of Snowglobe2?)
GCC 4.1 또는 이후 버젼의 C++ compiler.
- GCC 4.4 (Ubuntu 9.10에 설치된 버젼) 작업을 할수 없습니다, boost의 몇 부분 때문에 문제가 생깁니다. (http://svn.boost.org/trac/boost/ticket/2069). 해결 방법은 GCC 4.3을 설치하고 컴파일 하기전에 다음과 같이 환경 변수를 설정합니다. 'export CXX=/usr/bin/g++-4.3' 또는 GCC 4.1을 설치 하십시오.
  - apt-get install g++-4.1
  - update-alternatives --remove-all gcc
  - update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.1 41 --slave /usr/bin/g++ g++ /usr/bin/g++-4.1 --slave /usr/bin/gcov gcov /usr/bin/gcov-4.1
  - 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.1.:
  - update-alternatives --config gcc
- 과거에는 GCC 3.4을 추천 하였지만, 현재는 GCC 4 시리즈를 사용 해야합니다.
- libboost-program-options-dev가 Ubuntu 8.04에서 cmake를 사용하기 위해서 필요 하지만, 현재 Ubuntu 9.04-beta에서 1.23-render-pipeline을 빌드 하기 위해서는 더이상 필요하지 않습니다.(Ubuntu 9.10에서 Snowglobe 2 빌드시도 동일)

빌드를 위해서 선택적으로 설치 해도 되는 도구 :

distcc 분산 컴파일러 (여러대의 PC에서 병령 컴파일 할때 이용됩니다.)

소스 다운 받기

소스는 소스 보관소에서 Source downloads 다운 받거나 Subversion을 통해서 소스를 다운 받을수 있습니다. 빌드를 처음 하는 것이라면 소스 보관소에서 다운 받는 것을 추천합니다. 적극적으로 개발에 참여 하고 싶다면 Subversion를 이용 하시기 바랍니다. Subversion의 내용들을 Linden Lab에서 병합 하기까지 시간이 걸립니다.

소스 저장소에서 소스 받기

Source downloads 통해서 소스를 받습니다. 저장소에서 받아야할 3가지 : source, artwork 그리고 libraries (만약에 스노우글로브 (또는 'easybuild')의 경우 libraries를 자동으로 다운 받기때문에 별도로 다운 받을 필요가 없습니다. 하지만 artwork의 경우 여전히 다운 받아야합니다 )

소스와 art work의 압축을 풀경우 내용물은 linden 디렉토리 밑에 위치 하게 됩니다.

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

Subversion에서 소스 받기

branch로 부터 check out 할 소스를 선택합니다.

Check out 하는 법:

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

디렉토리를 따로 설정 하지 않으면 branch의 이름이 기본으로 설정 됩니다.

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.

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

% ln -sf <branch> linden

Now unpack the libraries and artwork:

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

라이브러리 설치 (린든랩에서 제공 하지 않는)

라이브러리와 헤더 파일

Make sure the libraries and header files for the following packages are installed on your system:

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

FMOD (audio)

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

Fetch and unpack FMOD 3.75 <http://www.fmod.org/>
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/index.php/release/version/fmodapi375linux.tar.gz
tar -xzvf fmodapi375linux.tar.gz
mkdir -p linden/libraries/i686-linux/lib_release_client/
mkdir -p linden/libraries/i686-linux/lib_debug/
mkdir -p linden/libraries/i686-linux/lib_release/
cd fmodapi375linux/
cp api/inc/* ../linden/libraries/i686-linux/include/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_debug/

FMOD is available free of charge, but it is not itself an open-source. We understand that some Linux users dislike to use software whose source is not open, and FMOD falls into this category. If you wish to avoid FMOD, thus disabling audio, you may make these changes:
- Comment-out the libfmod line in indra/newview/viewer_manifest.py

Installing the required dependencies (prepackaged by Linden Lab)

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

If you download the libs to the top folder, where the linden folder is after getting and extracting the viewer source code tarball, the following command should unpack everything to the right spot.

tar xvfz slviewer-linux-libs-<version>.tar.gz

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

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

Compiling with CMake

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 viewer versions 1.21 and beyond. For older viewers (1.20 and earlier) see Compiling the viewer with SCons (Linux)

Configuring your tree

Before you first run a build, you'll need to configure things. There's a develop.py 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: "./develop.py"
- KDevelop: "./develop.py -G KDevelop3"

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 develop.py script will create and populate a build directory for you. On Linux, this will be named viewer-linux-ARCH-BUILD (where "ARCH" is "i686" or "x86_64", and "BUILD" varies on debug level)
Build with your preferred build tool
1. Type make
  -- or---
2. Load it into KDevelop

Where's the built viewer?

On Linux, your build will be here:

viewer-linux-ARCH-BUILD/newview/packaged

...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 CXX containing the distcc command prefix to develop.py 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 g++, 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 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 appropriate number to -j 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 ccmake, you should see a STANDALONE option that determines whether the build will use your system's libraries or our prepackaged ones. Flipping this to ON 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 cmake will fail if a required library (such as OpenJPEG) isn't installed. We welcome all patches that help out with this.

cmake-SL: a script for standalone, pre-built and mixed libraries viewer builds under Linux.
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 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).

What to do if it doesn't work for you

Ask for help on IRC (irc.efnet.org #opensl)
Find someone on the 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.

Build the Viewer on Linux/ko

Contents