Second Life Wiki - User contributions [en]

Stuck logging in

2012-11-10T16:33:09Z

Lance Corrimal: Added how to reinstall the viewer on linux

{{Help|BugFixes=*}}

Problem: Resident is stuck logging in, or can't log in.

Possible Solutions:

* '''Make sure the grid is up.'''
** It should display "ONLINE", "RESTRICTED", or "OFFLINE" in the upper right part of your main screen.
*** If it says "OFFLINE", you can't access the grid.
*** If it says "RESTRICTED", only accounts that have payment info on file (and have used it at least once) can log on (only for peak activity times).
*** If it says "ONLINE", you should be able to access the grid.

* '''Make sure you're not being stopped by a firewall.'''
** If you are, change the settings to allow SecondLife.exe (or contact your system admin for corporate connections).

* '''Delete the files in Temporary and Cache directories on your hard disk.'''
''Note: If you have changed the location of your cache folder in your settings, replace the path to the cache folder in these instructions with your own setting''
: ''Windows''
:: * c:\documents and settings\<username>\Local Settings\Temp
:: * c:\documents and settings\<username>\Application Data\Secondlife\Cache
: ''Macintosh''
:: * /Users/<username>/Library/Application Support/SecondLife/cache
:: * /tmp/
: ''Linux''
:: * ~/.secondlife/cache
:: * /tmp/
:: ''Note: deleting all files in /tmp/ can have adverse effects on the stability of your linux desktop, you might want to relog to your computer at this point''

* '''Reinstall SL using a new copy from www.secondlife.com'''
: ''Windows''
:: * Uninstall SL through the Add/Remove Programs option in Control Panel.
:: * Reinstall SL.
: ''Macintosh''
:: * Delete temporary and cache directories as above.
:: * Delete "Second Life Viewer.app" from the /Applications directory.
:: * Reinstall SL.
: ''Linux''
:: * Delete temporary and cache directories as above.
:: * Delete the folder where you unpacked the tar file with the viewer you downloaded from www.secondlife.com
:: * Download the latest viewer from www.secondlife.com and install it as usual.

== Contributors ==
* [[User:Nova Linden|Nova Linden]]
* [[User:Peter Nelson|Peter Nelson]]
* [[User:Lance Corrimal|Lance Corrimal]]

[[Category:Text from In-world Notecards|Hotfixes, Login Problems]]

Stuck logging in

2012-11-10T16:30:19Z

Lance Corrimal: Added the missing linux details, updated the Mac OS instructions to reflect how Mac OS X handles these things

{{Help|BugFixes=*}}

Problem: Resident is stuck logging in, or can't log in.

Possible Solutions:

* '''Make sure the grid is up.'''
** It should display "ONLINE", "RESTRICTED", or "OFFLINE" in the upper right part of your main screen.
*** If it says "OFFLINE", you can't access the grid.
*** If it says "RESTRICTED", only accounts that have payment info on file (and have used it at least once) can log on (only for peak activity times).
*** If it says "ONLINE", you should be able to access the grid.

* '''Make sure you're not being stopped by a firewall.'''
** If you are, change the settings to allow SecondLife.exe (or contact your system admin for corporate connections).

* '''Delete the files in Temporary and Cache directories on your hard disk.'''
''Note: If you have changed the location of your cache folder in your settings, replace the path to the cache folder in these instructions with your own setting''
: ''Windows''
:: * c:\documents and settings\<username>\Local Settings\Temp
:: * c:\documents and settings\<username>\Application Data\Secondlife\Cache
: ''Macintosh''
:: * /Users/<username>/Library/Application Support/SecondLife/cache
:: * /tmp/
: ''Linux''
:: * ~/.secondlife/cache
:: * /tmp/
:: ''Note: deleting all files in /tmp/ can have adverse effects on the stability of your linux desktop, you might want to relog to your computer at this point''

* '''Reinstall SL using a new copy from www.secondlife.com'''
: ''Windows''
:: * Uninstall SL through the Add/Remove Programs option in Control Panel.
:: * Reinstall SL.
: ''Macintosh''
:: * Delete temporary and cache directories as above.
:: * Delete "Second Life Viewer.app" from the /Applications directory.
:: * Reinstall SL.

== Contributors ==
* [[User:Nova Linden|Nova Linden]]
* [[User:Peter Nelson|Peter Nelson]]
* [[User:Lance Corrimal|Lance Corrimal]]

[[Category:Text from In-world Notecards|Hotfixes, Login Problems]]

User:Lance Corrimal/Viewerhelp/Dolphin Viewer 3/

2012-03-06T12:00:12Z

Lance Corrimal: Created page with "test"

test

Release Notes/Dolphin Viewer 3/3.2.0

2011-12-10T18:29:47Z

Lance Corrimal:

====New or fixed in this version:====

*Based on 3.2.x sources now.
*Updated to Marine Kelley's latest RLV code.
*Fixed STORM-1713: Mouse pointer flickers over clickable UI items (from Ansariel Hiller / FireStorm).
*Client AO has been adapted to the new 3.2 toolbar button UI.
*Toolbar buttons for Windlight Settings and Area Search.
*You can now configure the viewer to turn you around when walking backwards.
Note: when this is ON, you will see it work on every avatar, not just yours, and other people using a viewer without it will still see you walk backwards. In short: this setting works on your screen, not inworld.
*Texture refresh from FireStorm has been imported.
This gives you an option labeled "Texture Refresh" in the context menu of inworld objects and avatars. When something is grey or blurry use this option to force a re-fetch of the textures involved.
*The particle editor from FireStorm has been imported.
When editing a prim you can choose "Edit Particles" from the Tools/Object menu, to create a particle effect in a more user-friendly way. You can create a simple particle script when you're done, or just copy the same script into your clipboard to paste it into a bigger script.

====Known issues:====

*There is no Flickr uploader for now. Porting that to the new snapshot code will take some more time, which I honestly do not have right now, due to RL commitments.
*There is still no working mesh upload. I've tried using the Firestorm code and the results weren't up to my standards.

====Work in progress:====

*Satomi Ahns login manager from Firestorm
*Flickr uploader
*Mesh upload

Release Notes/Dolphin Viewer 3/3.2.0

2011-12-10T18:26:42Z

Lance Corrimal: Blanked the page

Release Notes/Dolphin Viewer 3/3.2.0

2011-12-10T18:25:40Z

Lance Corrimal: Created page with "#redirect [dolphinviewer.eregion.de]"

#redirect [dolphinviewer.eregion.de]

Talk:NexiiText2

2011-09-21T09:14:56Z

Lance Corrimal: Created page with "an actual example how to create a display of N lines would be helpful. ~~~~"

an actual example how to create a display of N lines would be helpful. [[User:Lance Corrimal|Lance Corrimal]] 02:14, 21 September 2011 (PDT)

Roteiros:Cruises/Mallard River

2011-07-07T14:28:50Z

Lance Corrimal: Created page with "The cruise "Up the Mallard". Start anywhere in the Sansara inland sea, head to Orwood. From there keep going north following the Mallard River. At the…"

The cruise "Up the Mallard".

Start anywhere in the Sansara inland sea, head to [[Roteiros:Sims/Orwood|Orwood]].

From there keep going north following the Mallard River.

At the northern end you can either follow the coastline eastwards and go to Mowry Bay or follow the coastline westwards and wriggle your way into the fjords. With a small boat, a keen eye on the world map, and patience you can actually go all the way to Abbott's Aerodrome, or to the ANWR Straits to Heterocera.

Roteiros:Cruises

2011-07-07T14:23:55Z

Lance Corrimal: Created page with "Descriptions of longer cruises. Add links to subpages here. Roteiros:Cruises/Mallard River "

Descriptions of longer cruises.

Add links to subpages here.

[[ Roteiros:Cruises/Mallard River ]]

Roteiros:Sims

2011-07-07T14:23:06Z

Lance Corrimal:

Here is where the information is. Please add relevant stuff to subpages, one subpage per sim, naming the subpages after the simname.

[[ Roteiros:Sims/Orwood ]]

Roteiros:Sims/Orwood

2011-06-19T15:33:47Z

Lance Corrimal:

Located at the southern end of the Mallard River.

Small public rezzing spot at the southern border, close to Lauck's Nest.

WWC Setter, winds from the north.

Beware of the volcano in the center of the river mouth.

Roteiros:Sims/Orwood

2011-06-19T15:32:39Z

Lance Corrimal: Page about Orwood

Orwood, located at the southern end of the Mallard River.
Small public rezzing spot at the southern border, close to Lauck's Nest.
WWC Setter, winds from the north.

Roteiros:Sims

2011-06-19T15:30:08Z

Lance Corrimal: start opage for the sim list

Here is where the information is. Please add relevant stuff to subpages, one subpage per sim, naming the subpages after the simname.

Roteiros:About

2011-06-19T15:28:01Z

Lance Corrimal:

"Roteiro" means "route" in Portuguese. Anyone who has read "Shogun" (or watched the movie / tv series) should have heard the term before.In the old days, "Roteiro" was a (closely guarded) course description, used by navigators before the era of detailed, reliable maps.

The "Roteiros of Second Life" project aims at creating a collection of "Course descriptions and other information about navigating the grid".

Roteiros:About

2011-06-19T15:22:05Z

Lance Corrimal: Info page about the "Roteiros of SL"

"Roteiro" means "route" in Portuguese. Anyone who has read "Shogun" (or watched the movie / tv series) should have heard the term before; A "Roteiro" was a (closely guarded) course description, used by navigators before the era of detailed, reliable maps.

The "Roteiros of Second Life" project aims at creating a collection of "Course descriptions and other information about navigating the grid".

Build the Viewer on Linux

2011-04-06T09:41:48Z

Lance Corrimal: /* What to do if it doesn't work for you */

{{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 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.

* '''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 [[issue tracker|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
* '''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.)

{{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.}}

</onlyinclude>

== What does 'Standalone' mean? ==

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 <code>--standalone</code>, see [[#Configuring_your_tree|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://hg.secondlife.com).

{{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].}}

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

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

The following packages are required when building standalone, but even if you are building non-standalone you should probably install them.

{|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 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:

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

== Necessary libraries when building standalone ==

=== Existing package names ===

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

{|border="1" cellpadding="5" cellspacing="0"
|-
!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:

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

Fedora/Red Hat:

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

openSUSE:

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

<pre><nowiki>
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
</nowiki></pre>

=== 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 <code>/etc/apt/sources.list</code> and add the following lines:

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

or

# Repository for SecondLife.
deb <nowiki>http://apt.byteme.org.uk</nowiki> lenny main
deb-src <nowiki>http://apt.byteme.org.uk</nowiki> 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 <code>apt-get update</code> 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 [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:

% 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

# Openmetaverse repo
deb http://ppa.launchpad.net/openmetaverse/ppa/ubuntu lucid main

and of course to add the keys

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:

{|border="1" cellpadding="5" cellspacing="0"
|-
!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 <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:

# 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 <code><tut/tut.hpp></code> while
configure checks for <code>tut.h</code> in <code>/usr/lib</code> and <code>/usr/local/lib</code> 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 <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:

<code>
#include(FindTut)
#include_directories(${TUT_INCLUDE_DIR})
</code>

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:

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

=== 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|In earlier revisions, the package was named <code>vivox</code> rather than <code>slvoice</code>.}}

After [[#Compiling|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 --[[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/

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 <code>indra/newview/viewer_manifest.py</code> and comment out the following lines in <code>class Linux_i686Manifest(LinuxManifest)</code>:

<pre><nowiki>
#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")
</nowiki></pre>

Also, until [http://jira.secondlife.com/browse/VWR-9475 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 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.

'''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| 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_.27Standalone.27_mean.3F|What does 'standalone' mean?]]` above) choose an '''OpenSourceStandAlone''' option.
* If you want to use KDevelop add <code>-G KDevelop3</code>.
* 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: <code>-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" -DCMAKE_EXE_LINKER_FLAGS:STRING="$LDFLAGS"</code> 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 <code>-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON</code> as well.
* 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 restart the configuration process from scratch without any cached values affecting the configuration, erase the <code>CMakeCache.txt</code> in the build directory.

=== 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!)
* 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|submitting patches]].

----

{{KBcaution|
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 <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'
** ensure that you have indra/newview/app_settings/static_*.db2 - if not, you'll find it in the [[#slviewer-artwork-.3Cversion.3E.zip|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>

 
==== 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-.3Cversion.3E.tar.gz|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:
<code>
cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
mkdir "$SLSRC/indra/lib"
cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"
</code>

The file indra/newview/viewer_manifest.py contains some commented-out entries describing where these libraries belong; if you uncomment the two lines corresponding to libllkdu and libkdu then they will be automatically copied into the right place in the runtime directory when you follow the 'Packaging the client' instructions below.

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

* [[User:Henri Beauchamp/Automated Linux Build Script (1.20 and earlier)]]
* [[User:Henri Beauchamp/Building the viewer with CMake/cmake-SL script]]

* Please also see the (user contributed) instructions at [[User:Michelle2_Zenovka/cmake]]

=== FreeBSD ===

A list of patches is given for [[Compiling the viewer (FreeBSD)]]. They are obsolete, and no longer work.

[[Category:Compiling viewer]]

Build the Viewer on Linux

2011-04-01T13:54:48Z

Lance Corrimal: /* Existing package names */

{{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 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.

* '''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 [[issue tracker|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
* '''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.)

{{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.}}

</onlyinclude>

== What does 'Standalone' mean? ==

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 <code>--standalone</code>, see [[#Configuring_your_tree|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://hg.secondlife.com).

{{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].}}

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

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

The following packages are required when building standalone, but even if you are building non-standalone you should probably install them.

{|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 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:

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

== Necessary libraries when building standalone ==

=== Existing package names ===

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

{|border="1" cellpadding="5" cellspacing="0"
|-
!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:

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

Fedora/Red Hat:

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

openSUSE:

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

<pre><nowiki>
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
</nowiki></pre>

=== 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 <code>/etc/apt/sources.list</code> and add the following lines:

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

or

# Repository for SecondLife.
deb <nowiki>http://apt.byteme.org.uk</nowiki> lenny main
deb-src <nowiki>http://apt.byteme.org.uk</nowiki> 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 <code>apt-get update</code> 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 [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:

% 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

# Openmetaverse repo
deb http://ppa.launchpad.net/openmetaverse/ppa/ubuntu lucid main

and of course to add the keys

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:

{|border="1" cellpadding="5" cellspacing="0"
|-
!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 <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:

# 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 <code><tut/tut.hpp></code> while
configure checks for <code>tut.h</code> in <code>/usr/lib</code> and <code>/usr/local/lib</code> 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 <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:

<code>
#include(FindTut)
#include_directories(${TUT_INCLUDE_DIR})
</code>

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:

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

=== 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|In earlier revisions, the package was named <code>vivox</code> rather than <code>slvoice</code>.}}

After [[#Compiling|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 --[[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/

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 <code>indra/newview/viewer_manifest.py</code> and comment out the following lines in <code>class Linux_i686Manifest(LinuxManifest)</code>:

<pre><nowiki>
#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")
</nowiki></pre>

Also, until [http://jira.secondlife.com/browse/VWR-9475 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 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.

'''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| 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_.27Standalone.27_mean.3F|What does 'standalone' mean?]]` above) choose an '''OpenSourceStandAlone''' option.
* If you want to use KDevelop add <code>-G KDevelop3</code>.
* 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: <code>-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" -DCMAKE_EXE_LINKER_FLAGS:STRING="$LDFLAGS"</code> 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 <code>-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON</code> as well.
* 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 restart the configuration process from scratch without any cached values affecting the configuration, erase the <code>CMakeCache.txt</code> in the build directory.

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

----

{{KBcaution|
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 <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'
** ensure that you have indra/newview/app_settings/static_*.db2 - if not, you'll find it in the [[#slviewer-artwork-.3Cversion.3E.zip|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>

 
==== 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-.3Cversion.3E.tar.gz|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:
<code>
cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
mkdir "$SLSRC/indra/lib"
cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"
</code>

The file indra/newview/viewer_manifest.py contains some commented-out entries describing where these libraries belong; if you uncomment the two lines corresponding to libllkdu and libkdu then they will be automatically copied into the right place in the runtime directory when you follow the 'Packaging the client' instructions below.

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

* [[User:Henri Beauchamp/Automated Linux Build Script (1.20 and earlier)]]
* [[User:Henri Beauchamp/Building the viewer with CMake/cmake-SL script]]

* Please also see the (user contributed) instructions at [[User:Michelle2_Zenovka/cmake]]

=== FreeBSD ===

A list of patches is given for [[Compiling the viewer (FreeBSD)]]. They are obsolete, and no longer work.

[[Category:Compiling viewer]]

User:Lance Corrimal

2011-02-27T09:39:44Z

Lance Corrimal:

Developer of the [http://dolphinviewer.eregion.de Dolphin Viewer].

Lance Corrimal [http://twitter.com/lancecorrimal on twitter].

{{Jira Reporter}}

{{Tweeter}}

User:Lance Corrimal

2011-02-27T09:38:40Z

Lance Corrimal:

Developer of the [http://dolphinviewer.eregion.de Dolphin Viewer].

Lance Corrimal [http://twitter.com/lancecorrimal on twitter].

{{Tweeter}}

{{Jira Reporter}}

Release Notes/Dolphin Viewer 2/2.4.0

2011-01-26T15:39:18Z

Lance Corrimal: Created page with "Dolphin Viewer 2 is Lance Corrimal's next generation dolphin viewer based on the official 2.4.0 viewer, with most of the features from Dolphin. Dolphin Viewer can be found at ht…"

Dolphin Viewer 2 is Lance Corrimal's next generation dolphin viewer based on the official 2.4.0 viewer, with most of the features from Dolphin.

Dolphin Viewer can be found at http://dolphinviewer.eregion.de/

Talk:Third Party Viewer Directory

2010-12-11T18:10:55Z

Lance Corrimal:

The viewers listed as 2.x codebase are almost all 1.x codebase.

There is no Imprudence on 2.x

Kokua will be 2.x, but is not released yet.
----
The Dolphin Viewer is based on Snowglobe 1.5 svn 3627, not 1.23 [[User:Lance Corrimal|Lance Corrimal]] 18:10, 11 December 2010 (UTC)

As far as I know, kirsten is the only 2.x based TPV right now. [[User:Lance Corrimal|Lance Corrimal]] 18:10, 11 December 2010 (UTC)

Release Notes/Dolphin Viewer

2010-09-09T17:39:12Z

Lance Corrimal: Created page with 'The Dolphin Viewer is a Viewer for virtual worlds, based on Snowglobe 1.5 source, that contains many fixes and enhancements for explorers, sailors, and other vehicle enthusiasts....'

The Dolphin Viewer is a Viewer for virtual worlds, based on Snowglobe 1.5 source, that contains many fixes and enhancements for explorers, sailors, and other vehicle enthusiasts.

[http://dolphinviewer.eregion.de/ The Dolphin Viewer Homepage]

Release Notes/Dolphin Viewer/1.5

2010-09-09T12:35:29Z

User:Lance Corrimal

2010-04-28T07:28:08Z

Lance Corrimal:

{{Jira Reporter}}
[http://frozenglobe.eregion.de FrozenGlobe - a Cooler Snowglobe]