Second Life Wiki - User contributions [en]

User:Dale Glass

2008-11-02T11:12:17Z

Dale Glass: Preliminar notes on getting SL to build on ubuntu

Evil Scripter and RL programmer.

Currently working on adding an avatar scanner to the SL client.

= Projects =
== Avatar Scanner ==
http://daleglass.net/images/screenshots/avlist6_001.jpg

Features:
* Shows a list of all avatars known to the client. This can be easily more than a standard 96m scanner, and seems to depend on rendering distance.

* Keeps an internal list of avatars, and continues showing avatars that disappeared in the list for several seconds to give people time to perform some action on them (intended to make it easier to deal with griefers that do something nasty, then teleport out)

* Shows Linden accounts in bold. This will be expanded later to highlight people who are very new, don't have a credit card on file, etc depending on user configuration.

* Allows easy access to IM, profiles, etc

* Allows to start a conference to multiple avatars around you, the same way it works in the friends list.

* Allows tracking an avatar by placing a beacon on it. In the case the selected avatar isn't a friend who gave map location permission, it works anyway by placing a beacon on the avatar's last known position. This of course only works so long the avatar being tracked is near enough to be seen by the user.

* Automatically retrieves the birth date, account type and payment data for all users shown. The data is of course cached, and if this is too much of an extra load, I'll implement a permanent on-disk cache. If data doesn't arrive, it will retry with an exponential backoff (starting from 1 minute, doubling until 30 minutes)

* Displays activity status: new, left the area, emitting particles, moving, playing sound

* Allows moving the camera to the avatar with a double click, as well as cycling the camera between all or only the marked avatars

* Partial TrustNet integration: retrieves scores, but can't rate yet

What is not done yet, but will be:

* Integration with my TrustNet system. See here for details:
http://daleglass.net/tikiwiki/tiki-index.php?page=TrustNetAvatarScanner
http://daleglass.net/tikiwiki/tiki-index.php?page=HowTrustNetWorks

* Integration with resident-run databases. For example, I've been asked whether I could make it automatically query a website with a database of buyers to be able to tell people who are using avatars made with copybot, for instance.

* Buttons for administrative actions such as ban/eject/freeze/etc

* Add activity status for typing and rezzing objects

* Also longer term, option to make the client stop rendering an avatar completely.

'''Status''': Beta

'''SVN Repository''': http://svn.daleglass.net/sl/branches/avatarscanner

== TrustNet Integration ==
With the disappearance of SL ratings, I'm working on a replacement based on my TrustNet system. Current status is very experimental but with some functional code.

Here's a [http://daleglass.net/images/screenshots/trustnet_001.jpg screenshot] of what it looks like.

'''Status''': Alpha

'''SVN Repository''': http://svn.daleglass.net/sl/branches/trustnet

== Viewer/Script Communication ==
This is a hack to let a script talk to the viewer.

'''Status''': Stable

'''SVN Repository''': http://svn.daleglass.net/sl/branches/viewercomm

== Keyboard Hack ==
This is a viewer hack to make it transmit every keypress as a message on a channel. Used to implement an in-world keyboard that shows the real keypresses while the user is typing. General usage is discouraged, as this multiplies by 20-50 times the amount of chat messages sent to the sim and LL probably wouldn't like this sort of thing to be used widely.

'''Status''': Stable, but needs cleaning up and improvements.

'''SVN Repository''': http://svn.daleglass.net/sl/branches/realkeyboard

= Scripts =

* http://daleglass.net/scripts/load_archive.pl -- Script for loading source archives into Subversion. See comments in the source for usage.

= Subversion Repository =
The repository is located at [http://svn.daleglass.net/sl/ svn.daleglass.net]

== Branches ==
Current branches are:
* '''buildfixes_1-18-0''': 1.18.0 source, plus small compilation changes, for building with gcc4 and VC++ 2005. No functional changes here. Adds my installer.
* '''realkeyboard''': Silly patch that sends each keypress on a channel. Used to create a keyboard in SL that reflects my real keypresses.
* '''viewercomm''': Viewer/object communication patch
* '''avatarscanner''': Avatar scanner patch
* '''trustnet''': Support for my reputation system
* '''branding''': Branding changes: Different menu bar color, send crash reports to daleglass.net
* '''release''': Merge of various branches. This is where my installers are made from.
* '''trunk''': Currently unused
* '''log_object_owners''': Show owners and location of speaking objects in chat history

== How to get a patch ==
People sometimes ask me if I have patches. Currently I don't make them, because you can easily create an up to date one. Here's how:

<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/<branch> > patch
</code>

For example, to get a patch with my avatar scanner:
<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/avatarscanner > avatar-scanner.patch
</code>

This will create a patch with the difference between my '''buildfixes''' branch and another. This should apply cleanly to pristine sources.

== Branch Graph ==
Some branches are fed changes from others. This graph shows the hierarchy.

[[Image:Daleglass branch graph.png]]

= Installer =
My '''release''' branch (see above) is periodically packaged into an installer. If you get this, have in mind this is completely unofficial and unsupported by Linden Lab. Don't report bugs you find in it to LL.

This version will try to send crash reports to me, and not to LL. Updates will be downloaded from my server as well.

== Windows ==
The latest installer can be found at [http://sl.daleglass.net/ daleglass.net]

There's no autoupdate mechanism yet.

== Linux ==
I don't create Linux packages yet. You'll have to get the source from SVN and [[Compiling_the_viewer_(Linux) | build it]]

I may start making packages if there is demand.

== FreeBSD ==
I don't currently use BSD, so you'll have to get the source from SVN and [[Compiling_the_viewer_(FreeBSD) | build it]]

== OS X ==
I don't have any Mac hardware, so I can't create packages for it. I'm not currently planning to buy any either.

This means that Mac users will have to [[Compiling_the_viewer_(Mac_OS_X) | build it from source]], or get somebody to integrate my changes and create a package for them.

Despite this, anybody using it on a Mac is welcome to submit bug reports. If it's a Mac specific problem, I will appreciate information on how to fix it. The bug reporter will be expected to test the results for me, since I can't.

= Building viewer on Ubuntu 8.10 (Intrepid Ibex) =

Instructions in progress for quickly building the viewer under Ubuntu, in standalone mode:

Install these packages:
apt-get install g++ mesa-common-dev libglu1-mesa-dev libstdc++6.4.3-dev libx11-dev zlib1g-dev libssl-dev pkg-config libvorbis-dev libdb4.6-dev libapr1-dev libboost-dev libc-ares-dev libcurl4-openssl-dev libxmlrpc-epi-dev libopenjpeg-dev libjpeg-dev libpng-dev libsdl-dev libpango1.0-dev libgtk2.0-dev libgstreamer-plugins-base0.10-dev

Optionally, to use llmozlib:
apt-get install subversion cvs libglib-dev libidl-dev
svn co http://svn.secondlife.com/svn/llmozlib/trunk/llmozlib2
cd llmozlib2
gcc_version=`readlink /usr/bin/gcc | sed -r "s/^.*?-//'
sed 's/GCC_VERSION=.*$/GCC_VERSION=${gcc_version}/" build_mozilla/linux-libxul-bits/mozconfig > build_mozilla/linux-libxul-bits/mozconfig.tmp
mv -f build_mozilla/linux-libxul-bits/mozconfig.tmp build_mozilla/linux-libxul-bits/mozconfig
cd build_mozilla
./linux-checkout_patch_build.sh

To build, artwork is needed.
wget $artwork
unzip $artwork

Ubuntu doesn't come with the right version of cmake, build it:
wget http://www.cmake.org/files/v2.6/cmake-2.6.2.tar.gz
tar -xzvf cmake-2.6.2.tar.gz
cd cmake-2.6.2
./configure
make
make install

= Etc =
{{Jira Reporter}}

User:Dale Glass

2007-11-17T00:01:04Z

Dale Glass: /* Windows */

LSL To Client Communication

2007-10-30T00:28:37Z

Dale Glass: script compilation and bugfixes

{{Open Source Portal}}

=Communication=
A mechanism is needed to allow LSL scripts to talk to the viewer in order to allow implementing some interesting functionality, such as viewer UI extensions that communicate with in-world objects, for instance. Viewer to LSL communication is easily possible, by making the viewer talk on a specific channel, or use XML RPC. This may not be ideal for all cases, but it's already doable without any modifications.

What needs work is LSL to Client communication, as there currently isn't any good method in the official client for that.

=Requirements=
A robust mechanism should satisfy these requirements:

# Scripts must be able to receive messages from the viewer (can be done already with chat and XML RPC)
# Scripts must be able to reply to the viewer
# It must be possible to communicate with multiple viewers at once without confusion
# Order of delivery must be guaranteed (chat messages currently can be reordered)
# Messages must be reliable

The hack below can satisfy requirements #1 to #3. Requirement #4 would require extra work (although it's doable) and is possibly best ignored, as LL mentioned the possibility of moving chat to TCP, which would automatically solve the issue.

Requirement #5 is mostly satisfied as data isn't lost, and the only problem may be with the viewer or the script disappearing, which can be dealt with by designing the proper protocol, if needed.

=Hack=
While there's no official solution, here's what I came up with for now:

* Client to LSL: Client speaks on a channel directly. Nothing special here.
* LSL to Client: Script uses llOwnerSay, with this format:

<pre><nowiki>
$VwrComm$VERSION$COMPONENT$DATA
</nowiki></pre>

Fields:
* VwrComm: Header, must be present
* VERSION: Protocol version
* COMPONENT: Component inside the viewer the message is for
* DATA: Data being sent. The format of the data isn't specified.

==Behavior==

This is how the current implementation handles the protocol:

# Message must come from an object. Normal chat doesn't trigger it
# String gets split by "$" and must have at least 4 tokens
# First token must be VwrComm
# Second token must be "0" (version number, this will change)
# Third token matches the name of a known component.

If requirements #1 to #3 aren't satisfied, the string is passed as-is, and the code doesn't suppress its display.

If requirement #4 isn't satisfied, the text won't appear on screen, but the code won't continue further either. A message will be logged in the viewer's log, saying that a message with the wrong version was received.

If requirement #5 isn't satisfied, display is also suppressed, and a message is also logged.

If all those requirements are satisfied, the data in the message is sent to the specified part of the viewer for futher processing.

==Example==

<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

==Implementation==
Code for this can be found at [http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp], line 2047

Note that at the time of writing, the client isn't capable of telling the difference between object speech sent to all users (llSay/etc) and object speech sent only to the owner (llOwnerSay). It also doesn't check the speaking object's key or its owner's. This code must be fixed to obtain that information, so that the viewer can ignore messages from objects not owned by the user, when such a thing is necessary.

=Protocol=
The above describes the system and format for exchanging data. However, there are still a few problems to solve:

# Multiple extensions to the viewer must be able to coexist, without conflicting with others
# Viewer may not implement this at all, in which case the messages get displayed on screen
# Viewer replies to the script have potential security issues

Proposed solutions:

# See next section
# The LSL script initiates the conversation. It sends a single request and waits for a reply. This ensures that non-supporting clients don't get flooded with protocol data.
# During the establishment of the connection, the script chooses a random channel to listen on, and tells it to the viewer. This makes it very improbable that somebody will be able to intercept the data, as the channel will be different every time. An additional advantage is that there's no need to keep track of who uses what channel: the chance of a collision should be extremely low.

== Component Naming ==
The COMPONENT field of the protocol specifies the name of the component inside the viewer the script wants to talk to. The data is an arbitrary ASCII string, which may not contain newlines or the $ character. The proposed format is "AvatarName.FunctionName", where AvatarName is the first and last names of the avatar who created the functionality concatenated without a space, a period, and the name of the avatar's creation. This system should ensure that should two people come up with different ways to do the same thing, the COMPONENT names won't clash.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

== Connection Establishment ==
As described above, the LSL script initiates the communication by telling the viewer what channel it wants to talk on.

=== Connection Request ===
* The COMPONENT field's value is "DaleGlass.Viewer"
* The payload is "Connect$<channel>"

The fields are as follows:
* <channel> is the channel the script wants to talk on. For security, this SHOULD be randomly generated. The channel number '''must be positive''', since the viewer can't talk on negative channel numbers. It's recommended to exclude channels < 1000 or so, to avoid highly used channel numbers.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.Viewer$Connect$12421
</nowiki></pre>

=== Viewer Reply ===
Viewer replies to the request by sending the message "OK" to the specified channel. Any other reply MUST be considered an error message.

After this, any further requests to the viewer from the object are replied to in on the specified channel.

=== Example ===
<pre><nowiki>
integer g_channel = 0; // Channel to talk on -- randomly generated
integer g_listen_handle = 0; // Listen handle

integer g_timeout = 30; // How long to wait for the viewer to reply

ViewerComm(string component, string data) {
llOwnerSay("$VwrComm$0$" + component + "$" + data);
}

default {
state_entry() {
// Generate a random channel number
g_channel = (integer)(llFrand(2147482646.0) + 1000.0);

// Set a timer in case the viewer doesn't reply
llSetTimerEvent(g_timeout);

// Listen for replies
g_listen_handle = llListen(g_channel, "", llGetOwner(), "");

// Send connection request
ViewerComm("DaleGlass.Viewer", "Connect$" + (string)g_channel);
}

timer() {
llSetTimerEvent(0.0); // Disable timeout timer
llListenRemove(g_listen_handle);
llOwnerSay("Client/Viewer connection timed out -- probably not supported");
}

listen( integer channel, string name, key id, string message ) {
llSetTimerEvent(0.0); // Disable timeout timer

if ( message == "OK" ) {
// Connection successful
llOwnerSay("Client/Viewer connection successful");
} else {
// Something went wrong
llOwnerSay("Client/Viewer connection error: " + message);
}
}
}
</nowiki></pre>

= General Functionality =
This is the proposed functionality that would be implemented by the main patch itself, and supported by all viewers that speak this protocol. The idea is to provide some simple and generally useful functionality. All of them would use COMPONENT "DaleGlass.Viewer".

== GetViewerVersion ==
This command would return the viewer's version as a string, with the following format:
<pre><nowiki>
<major>$<minor>$<revision>$<build>
</nowiki></pre>

For example, viewer version 1.17.0 (12) would be sent as:
<pre><nowiki>
1$17$0$12
</nowiki></pre>

== GetViewerBuilder ==
Returns the name of the person who built the viewer. "Linden Lab" would be reserved for LL. My viewer would say "Dale Glass" here for instance.

== GetViewerRevision ==
Returns the viewer's revision number. This would apply only to custom built viewers. The recommendation is that the reply to this message be the revision number from the builder's source repository.

== GetExtensionList ==
Returns the list of supported viewer extensions, as a comma separated string. MUST NOT contain anything that'd conflict with llCSV2List.

Example reply:
<pre><nowiki>
DaleGlass.Viewer, DaleGlass.AvatarScanner, ExampleAvatar.CoolScript
</nowiki></pre>

The intention behind this command is allowing scripts that are capable of using multiple extensions determine which are present.

== GetOperatingSystem ==
Returns a string describing the OS being used:
* Linux
* Windows
* OS X
* Solaris
* (etc)

The intention is to allow scripts to determine that some functionality isn't available because the implementation is OS-specific. This MUST NOT be used as a primary method of detecting whether some functionality is supported (as this could change). Instead, this should only be used after GetExtensionList fails to return the desired functionality, and used to determine whether the lack of it is because it's not available on that OS at all.

=See Also=

See also: Q re client app current/ obsolete/ Mac/ Linux/ Windows/ LSL-Editor/ what at [[LlRequestClientData]]

[[Category:Design Discussions]]

LSL To Client Communication

2007-10-27T19:53:23Z

Dale Glass: corrected information about channel numbers

{{Open Source Portal}}

=Communication=
A mechanism is needed to allow LSL scripts to talk to the viewer in order to allow implementing some interesting functionality, such as viewer UI extensions that communicate with in-world objects, for instance. Viewer to LSL communication is easily possible, by making the viewer talk on a specific channel, or use XML RPC. This may not be ideal for all cases, but it's already doable without any modifications.

What needs work is LSL to Client communication, as there currently isn't any good method in the official client for that.

=Requirements=
A robust mechanism should satisfy these requirements:

# Scripts must be able to receive messages from the viewer (can be done already with chat and XML RPC)
# Scripts must be able to reply to the viewer
# It must be possible to communicate with multiple viewers at once without confusion
# Order of delivery must be guaranteed (chat messages currently can be reordered)
# Messages must be reliable

The hack below can satisfy requirements #1 to #3. Requirement #4 would require extra work (although it's doable) and is possibly best ignored, as LL mentioned the possibility of moving chat to TCP, which would automatically solve the issue.

Requirement #5 is mostly satisfied as data isn't lost, and the only problem may be with the viewer or the script disappearing, which can be dealt with by designing the proper protocol, if needed.

=Hack=
While there's no official solution, here's what I came up with for now:

* Client to LSL: Client speaks on a channel directly. Nothing special here.
* LSL to Client: Script uses llOwnerSay, with this format:

<pre><nowiki>
$VwrComm$VERSION$COMPONENT$DATA
</nowiki></pre>

Fields:
* VwrComm: Header, must be present
* VERSION: Protocol version
* COMPONENT: Component inside the viewer the message is for
* DATA: Data being sent. The format of the data isn't specified.

==Behavior==

This is how the current implementation handles the protocol:

# Message must come from an object. Normal chat doesn't trigger it
# String gets split by "$" and must have at least 4 tokens
# First token must be VwrComm
# Second token must be "0" (version number, this will change)
# Third token matches the name of a known component.

If requirements #1 to #3 aren't satisfied, the string is passed as-is, and the code doesn't suppress its display.

If requirement #4 isn't satisfied, the text won't appear on screen, but the code won't continue further either. A message will be logged in the viewer's log, saying that a message with the wrong version was received.

If requirement #5 isn't satisfied, display is also suppressed, and a message is also logged.

If all those requirements are satisfied, the data in the message is sent to the specified part of the viewer for futher processing.

==Example==

<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

==Implementation==
Code for this can be found at [http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp], line 2047

Note that at the time of writing, the client isn't capable of telling the difference between object speech sent to all users (llSay/etc) and object speech sent only to the owner (llOwnerSay). It also doesn't check the speaking object's key or its owner's. This code must be fixed to obtain that information, so that the viewer can ignore messages from objects not owned by the user, when such a thing is necessary.

=Protocol=
The above describes the system and format for exchanging data. However, there are still a few problems to solve:

# Multiple extensions to the viewer must be able to coexist, without conflicting with others
# Viewer may not implement this at all, in which case the messages get displayed on screen
# Viewer replies to the script have potential security issues

Proposed solutions:

# See next section
# The LSL script initiates the conversation. It sends a single request and waits for a reply. This ensures that non-supporting clients don't get flooded with protocol data.
# During the establishment of the connection, the script chooses a random channel to listen on, and tells it to the viewer. This makes it very improbable that somebody will be able to intercept the data, as the channel will be different every time. An additional advantage is that there's no need to keep track of who uses what channel: the chance of a collision should be extremely low.

== Component Naming ==
The COMPONENT field of the protocol specifies the name of the component inside the viewer the script wants to talk to. The data is an arbitrary ASCII string, which may not contain newlines or the $ character. The proposed format is "AvatarName.FunctionName", where AvatarName is the first and last names of the avatar who created the functionality concatenated without a space, a period, and the name of the avatar's creation. This system should ensure that should two people come up with different ways to do the same thing, the COMPONENT names won't clash.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

== Connection Establishment ==
As described above, the LSL script initiates the communication by telling the viewer what channel it wants to talk on.

=== Connection Request ===
* The COMPONENT field's value is "DaleGlass.Viewer"
* The payload is "Connect$<channel>"

The fields are as follows:
* <channel> is the channel the script wants to talk on. For security, this SHOULD be randomly generated. The channel number '''must be positive''', since the viewer can't talk on negative channel numbers. It's recommended to exclude channels < 1000 or so, to avoid highly used channel numbers.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.Viewer$Connect$12421
</nowiki></pre>

=== Viewer Reply ===
Viewer replies to the request by sending the message "OK" to the specified channel. Any other reply MUST be considered an error message.

After this, any further requests to the viewer from the object are replied to in on the specified channel.

=== Example ===
<pre><nowiki>
integer g_channel = 0; // Channel to talk on -- randomly generated
integer g_listen_handle = 0; // Listen handle

integer g_timeout = 30; // How long to wait for the viewer to reply

ViewerComm(string component, string data) {
llOwnerSay("$VwrComm$0$" + component + "$" + data);
}

default {
state_entry() {
// Generate a random channel number
g_channel = (integer)(llFrand(2147482646.0) + 1000.0);

// Set a timer in case the viewer doesn't reply
llSetTimerEvent(g_timeout);

// Listen for replies
g_listen_handle = llListen(g_channel, "", llGetOwner(), "");

// Send connection request
ViewerComm("DaleGlass.Viewer", "Connect$" + (string)channel);
}

timer() {
llListenRemove(g_listen_handle);
llOwnerSay("Client/Viewer connection timed out -- probably not supported");
}

listen( integer channel, string name, key id, string message ) {
if ( message == "OK" ) {
// Connection successful
llOwnerSay("Client/Viewer connection successful");
} else {
// Something went wrong
llOwnerSay("Client/Viewer connection error: " + message);
}
}
}
</nowiki></pre>

= General Functionality =
This is the proposed functionality that would be implemented by the main patch itself, and supported by all viewers that speak this protocol. The idea is to provide some simple and generally useful functionality. All of them would use COMPONENT "DaleGlass.Viewer".

== GetViewerVersion ==
This command would return the viewer's version as a string, with the following format:
<pre><nowiki>
<major>$<minor>$<revision>$<build>
</nowiki></pre>

For example, viewer version 1.17.0 (12) would be sent as:
<pre><nowiki>
1$17$0$12
</nowiki></pre>

== GetViewerBuilder ==
Returns the name of the person who built the viewer. "Linden Lab" would be reserved for LL. My viewer would say "Dale Glass" here for instance.

== GetViewerRevision ==
Returns the viewer's revision number. This would apply only to custom built viewers. The recommendation is that the reply to this message be the revision number from the builder's source repository.

== GetExtensionList ==
Returns the list of supported viewer extensions, as a comma separated string. MUST NOT contain anything that'd conflict with llCSV2List.

Example reply:
<pre><nowiki>
DaleGlass.Viewer, DaleGlass.AvatarScanner, ExampleAvatar.CoolScript
</nowiki></pre>

The intention behind this command is allowing scripts that are capable of using multiple extensions determine which are present.

== GetOperatingSystem ==
Returns a string describing the OS being used:
* Linux
* Windows
* OS X
* Solaris
* (etc)

The intention is to allow scripts to determine that some functionality isn't available because the implementation is OS-specific. This MUST NOT be used as a primary method of detecting whether some functionality is supported (as this could change). Instead, this should only be used after GetExtensionList fails to return the desired functionality, and used to determine whether the lack of it is because it's not available on that OS at all.

=See Also=

See also: Q re client app current/ obsolete/ Mac/ Linux/ Windows/ LSL-Editor/ what at [[LlRequestClientData]]

[[Category:Design Discussions]]

LSL To Client Communication

2007-10-27T19:50:39Z

Dale Glass: corrected channel number calculation

{{Open Source Portal}}

=Communication=
A mechanism is needed to allow LSL scripts to talk to the viewer in order to allow implementing some interesting functionality, such as viewer UI extensions that communicate with in-world objects, for instance. Viewer to LSL communication is easily possible, by making the viewer talk on a specific channel, or use XML RPC. This may not be ideal for all cases, but it's already doable without any modifications.

What needs work is LSL to Client communication, as there currently isn't any good method in the official client for that.

=Requirements=
A robust mechanism should satisfy these requirements:

# Scripts must be able to receive messages from the viewer (can be done already with chat and XML RPC)
# Scripts must be able to reply to the viewer
# It must be possible to communicate with multiple viewers at once without confusion
# Order of delivery must be guaranteed (chat messages currently can be reordered)
# Messages must be reliable

The hack below can satisfy requirements #1 to #3. Requirement #4 would require extra work (although it's doable) and is possibly best ignored, as LL mentioned the possibility of moving chat to TCP, which would automatically solve the issue.

Requirement #5 is mostly satisfied as data isn't lost, and the only problem may be with the viewer or the script disappearing, which can be dealt with by designing the proper protocol, if needed.

=Hack=
While there's no official solution, here's what I came up with for now:

* Client to LSL: Client speaks on a channel directly. Nothing special here.
* LSL to Client: Script uses llOwnerSay, with this format:

<pre><nowiki>
$VwrComm$VERSION$COMPONENT$DATA
</nowiki></pre>

Fields:
* VwrComm: Header, must be present
* VERSION: Protocol version
* COMPONENT: Component inside the viewer the message is for
* DATA: Data being sent. The format of the data isn't specified.

==Behavior==

This is how the current implementation handles the protocol:

# Message must come from an object. Normal chat doesn't trigger it
# String gets split by "$" and must have at least 4 tokens
# First token must be VwrComm
# Second token must be "0" (version number, this will change)
# Third token matches the name of a known component.

If requirements #1 to #3 aren't satisfied, the string is passed as-is, and the code doesn't suppress its display.

If requirement #4 isn't satisfied, the text won't appear on screen, but the code won't continue further either. A message will be logged in the viewer's log, saying that a message with the wrong version was received.

If requirement #5 isn't satisfied, display is also suppressed, and a message is also logged.

If all those requirements are satisfied, the data in the message is sent to the specified part of the viewer for futher processing.

==Example==

<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

==Implementation==
Code for this can be found at [http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp], line 2047

Note that at the time of writing, the client isn't capable of telling the difference between object speech sent to all users (llSay/etc) and object speech sent only to the owner (llOwnerSay). It also doesn't check the speaking object's key or its owner's. This code must be fixed to obtain that information, so that the viewer can ignore messages from objects not owned by the user, when such a thing is necessary.

=Protocol=
The above describes the system and format for exchanging data. However, there are still a few problems to solve:

# Multiple extensions to the viewer must be able to coexist, without conflicting with others
# Viewer may not implement this at all, in which case the messages get displayed on screen
# Viewer replies to the script have potential security issues

Proposed solutions:

# See next section
# The LSL script initiates the conversation. It sends a single request and waits for a reply. This ensures that non-supporting clients don't get flooded with protocol data.
# During the establishment of the connection, the script chooses a random channel to listen on, and tells it to the viewer. This makes it very improbable that somebody will be able to intercept the data, as the channel will be different every time. An additional advantage is that there's no need to keep track of who uses what channel: the chance of a collision should be extremely low.

== Component Naming ==
The COMPONENT field of the protocol specifies the name of the component inside the viewer the script wants to talk to. The data is an arbitrary ASCII string, which may not contain newlines or the $ character. The proposed format is "AvatarName.FunctionName", where AvatarName is the first and last names of the avatar who created the functionality concatenated without a space, a period, and the name of the avatar's creation. This system should ensure that should two people come up with different ways to do the same thing, the COMPONENT names won't clash.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

== Connection Establishment ==
As described above, the LSL script initiates the communication by telling the viewer what channel it wants to talk on.

=== Connection Request ===
* The COMPONENT field's value is "DaleGlass.Viewer"
* The payload is "Connect$<channel>"

The fields are as follows:
* <channel> is the channel the script wants to talk on. For security, this SHOULD be randomly generated.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.Viewer$Connect$12421
</nowiki></pre>

=== Viewer Reply ===
Viewer replies to the request by sending the message "OK" to the specified channel. Any other reply MUST be considered an error message.

After this, any further requests to the viewer from the object are replied to in on the specified channel.

=== Example ===
<pre><nowiki>
integer g_channel = 0; // Channel to talk on -- randomly generated
integer g_listen_handle = 0; // Listen handle

integer g_timeout = 30; // How long to wait for the viewer to reply

ViewerComm(string component, string data) {
llOwnerSay("$VwrComm$0$" + component + "$" + data);
}

default {
state_entry() {
// Generate a random channel number
g_channel = (integer)(llFrand(2147482646.0) + 1000.0);

// Set a timer in case the viewer doesn't reply
llSetTimerEvent(g_timeout);

// Listen for replies
g_listen_handle = llListen(g_channel, "", llGetOwner(), "");

// Send connection request
ViewerComm("DaleGlass.Viewer", "Connect$" + (string)channel);
}

timer() {
llListenRemove(g_listen_handle);
llOwnerSay("Client/Viewer connection timed out -- probably not supported");
}

listen( integer channel, string name, key id, string message ) {
if ( message == "OK" ) {
// Connection successful
llOwnerSay("Client/Viewer connection successful");
} else {
// Something went wrong
llOwnerSay("Client/Viewer connection error: " + message);
}
}
}
</nowiki></pre>

= General Functionality =
This is the proposed functionality that would be implemented by the main patch itself, and supported by all viewers that speak this protocol. The idea is to provide some simple and generally useful functionality. All of them would use COMPONENT "DaleGlass.Viewer".

== GetViewerVersion ==
This command would return the viewer's version as a string, with the following format:
<pre><nowiki>
<major>$<minor>$<revision>$<build>
</nowiki></pre>

For example, viewer version 1.17.0 (12) would be sent as:
<pre><nowiki>
1$17$0$12
</nowiki></pre>

== GetViewerBuilder ==
Returns the name of the person who built the viewer. "Linden Lab" would be reserved for LL. My viewer would say "Dale Glass" here for instance.

== GetViewerRevision ==
Returns the viewer's revision number. This would apply only to custom built viewers. The recommendation is that the reply to this message be the revision number from the builder's source repository.

== GetExtensionList ==
Returns the list of supported viewer extensions, as a comma separated string. MUST NOT contain anything that'd conflict with llCSV2List.

Example reply:
<pre><nowiki>
DaleGlass.Viewer, DaleGlass.AvatarScanner, ExampleAvatar.CoolScript
</nowiki></pre>

The intention behind this command is allowing scripts that are capable of using multiple extensions determine which are present.

== GetOperatingSystem ==
Returns a string describing the OS being used:
* Linux
* Windows
* OS X
* Solaris
* (etc)

The intention is to allow scripts to determine that some functionality isn't available because the implementation is OS-specific. This MUST NOT be used as a primary method of detecting whether some functionality is supported (as this could change). Instead, this should only be used after GetExtensionList fails to return the desired functionality, and used to determine whether the lack of it is because it's not available on that OS at all.

=See Also=

See also: Q re client app current/ obsolete/ Mac/ Linux/ Windows/ LSL-Editor/ what at [[LlRequestClientData]]

[[Category:Design Discussions]]

Viewer Authentication Critique

2007-09-29T21:28:18Z

Dale Glass: /* Signatories */

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Security ==

=== LL's Objectives ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* Viewer still involves running trusted code on the computer and could initiate other attacks e.g.
** Silently buy L$ and pass onto another account
** Pass token onto bot, and drop the users connection
** Install key logger to monitor the next website login
** Salami slicing - make additional small or duplicate payments to cutout when user purchases or pays in game.
* Potential for naive user to believe this reduces all risks in using a third party viewer.
* Most of these attacks could be performed by any third-party software designed for use with SL
** A local support program could install a keylogger.
** A local support program could inject code into the client.
** Look at 'cheating' tools in MMORPGs for possible approaches.
* Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
** This kind of attack is not theoretical, phishing websites are a criminal industry.
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next section would mean that people would have an incentive to use this kind of client.
* Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
* Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
* Links to secondlife:// can not pass parameters to the program

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* CRAM-MD5 or a similar challenge-response type
* Dictionary check to reject insecure passwords
=== Other Issues ===
* The main existing vulnerability involving the viewer and passwords is that the viewer does not use a cryptographically secure mechanism to pass the password to the server, not that the viewer may be stealing the password.
* In practice, trapdoored unofficial third party clients for applications have not historically been a major problem. This seems to be attacking an exposure that is primarily theoretical, and using a mechanism that has been known to be exploited to solve it.
 
 

== Flexibility ==

=== LL's Objectives ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** CAS - [http://www.ja-sig.org/products/cas/]
 
 
 
== Persistence ==

=== LL's Objectives ===
* To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===

=== Cons ===
* As in the previous section, LL's objectives could be met without the browser logging in via the same mechanism.
* Inconvenient for those with alts
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
* Inconvenient for those with multiple clients
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld

=== Alternatives ===
* Is this really needed?
=== Other issues ===
* Is this kind of persistence desirable ''for the client''? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".
 
 
 

== Misc ==

* this should be an option for those who have increased security needs, users should be able to make their own risk/convenience decisions
* the feature especially forces those into an extra login step, who use an official viewer (homebrews will most likely quickly implement a way around this for convenience)
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would make things harder for independent grids to use the official client. Is this considered an advantage or a disadvantage by LL?

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)

Viewer Authentication Critique

2007-09-29T18:47:35Z

Dale Glass: Added account restrictions to alternatives list

== Security ==

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* Viewer still involves running trusted code on the computer and could initiate other attacks e.g.
** Silently buy L$ and pass onto another account
** Pass token onto bot, and drop the users connection
** Install key logger
* Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
* Too reliant on browser/OS implementations
* Relies on browser security, and uses a mechanism often disabled due to security concerns

=== Alternatives ===
* One time passwords
* Account restrictions

== Flexibility ==

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
* OpenID
* CardSpace
* Identity Metasystem

== Persistence ==

=== Pros ===

=== Cons ===
* Inconvenient for those with alts
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
* Inconvenient for those with multiple clients
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.

=== Alternatives ===
* Is this really needed?

----
--[[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)

Bug triage/2007-09-17

2007-09-17T17:08:41Z

Dale Glass: Add VWR-2502

{{Bug triage}}

General triage - Next meeting: Monday, 3pm PT (2007-09-17) in the {{SLurl
|region=Hippotropolis
|x=241
|y=27
|z=23
|title=Hippotropolis Meeting area
|}}. See [[Bug triage]] for details.

== Fast Track Import ==

(Move bugs here that have solid repros, or valid patches that you have reviewed)

== Hot by Vote ==
* {{jira|MISC-33}} - Votes: 68 - Risk API false positives increase - {{User|Apotheus Silverman}}
** worse since 2007-08-25 --> reopened
** better again since 2007-09-13
* {{jira|SVC-553}} - Votes: 24 - numerous reports of objects, notecards, scripts, gestures "missing from database" - {{User|Lex Neva}}
** already triaged at [[Bug_triage/2007-08-20#Hot_by_Vote]]
** looks like no action has been taken back then
* {{jira|SVC-523}} - Votes: 15 - Object entry restriction not enabling on parcel - {{User|leena deschanel}}
* {{jira|WEB-104}} - Votes: 13 - Downloaded transactions do not include Region - {{User|alpha2 zenovka}}
* {{jira|MISC-326}} - Votes: 13 - Governor Linden owned parcels do not have uniform parcel settings which allows griefers to create parcel infringing and other objectionable objects that are not affected by auto-return. - {{User|Hoshi Kiama}}
* {{jira|VWR-852}} - Votes: 11 - no-transfer textures not searchable via texture picker - {{User|SignpostMarv Martin}}
* {{jira|VWR-1108}} - Votes: 10 - No voice and related functions - {{User|Aodhan McDunnough}}
* {{jira|MISC-325}} - Votes: 10 - Avatar arms and legs turn black / psychedelic - {{User|sasha vollmar}}
* {{jira|VWR-2390}} - Votes: 9 - unable to select texture on a friend's prim despite full permissions - {{User|McCabe Maxsted}}
* {{jira|VWR-1319}} - Votes: 9 - USB headset on Mac works differently on mainland vs. islands - {{User|martholomew mip}}
* {{jira|VWR-996}} - Votes: 8 - wrong visualisation of animations - {{User|Doris Haller}}
* {{jira|VWR-1799}} - Votes: 8 - Voice not Working - {{User|Taran Asbrink}}
* {{jira|SVC-483}} - Votes: 8 - Script is missing from Database - {{User|Laronzo Fitzgerald}}
* {{jira|VWR-2148}} - Votes: 8 - Object Missing from Database - {{User|silas scarborough}}
* {{jira|VWR-2387}} - Votes: 8 - Animations always drift when uploading with an inner loop of anything except 0% - 100% - {{User|Chavo Raven}}
* {{jira|VWR-2502}} - Votes: 8 - Add mute button to script notices - {{User|Dale Glass}}

== Patches ==
* {{jira|VWR-1677}} - Votes: 0 - Ctrl+T does not return focus to the chat bar in IM window - {{User|Feynt Mistral}}
** according to Nicholaz, the patch is a 'sketch version', based on his source (and therefore old school IM windows)--[[User:Boroondas Gupte|Boroondas Gupte]] 14:03, 15 September 2007 (PDT)
* {{jira|VWR-2113}} - Votes: 0 - Mac Auto Updater "hides", giving appearance of failing - {{User|Gibson Willis}}
** one-liner
* {{jira|SVC-580}} - Votes: 1 - ATTACH_LPEC / ATTACH_RPEC reversed - {{User|Ziggy Puff}}
** '''will''' break existing scripts relying on current (wrong) naming of the constants, but '''only when they're being recompiled'''
** otherwise safe--[[User:Boroondas Gupte|Boroondas Gupte]] 14:03, 15 September 2007 (PDT)
* {{jira|VWR-2255}} - Votes: 1 - Mac updater does not log output. - {{User|Grazer Kline}}
* {{jira|VWR-2256}} - Votes: 1 - Mac updater directory permission issues - {{User|Grazer Kline}}
* {{jira|VWR-2411}} - Votes: 0 - Possible crash in pipeline.cpp - {{User|Nicholaz Beresford}}
** adds a check, should be safe--[[User:Boroondas Gupte|Boroondas Gupte]] 14:03, 15 September 2007 (PDT)
* {{jira|VWR-2412}} - Votes: 0 - Possible crash drawpoolwater - {{User|Nicholaz Beresford}}
** same here--[[User:Boroondas Gupte|Boroondas Gupte]] 14:03, 15 September 2007 (PDT)

== Misc Pool ==
* {{jira|SVC-29}} - Votes: 2 - XMLRPC sporadically (but usually) very slow - {{User|Apotheus Silverman}}
* {{jira|MISC-33}} - Votes: 68 - Risk API false positives increase - {{User|Apotheus Silverman}}
* {{jira|SVC-120}} - Votes: 0 - Objects -> Permissions -> Modify Rights -> affects Return ability - {{User|Gigs Taggart}}
* {{jira|WEB-86}} - Votes: 3 - Transaction History Total Bug when paying self owned object - {{User|Gypsy Paz}}
* {{jira|VWR-2426}} - Votes: 1 - Missing character in email sent with llEmail - {{User|Simil Miles}}
* {{jira|VWR-500}} - Votes: 4 - Searching inventory for "copy", "modify" etc brings up everything. - {{User|Gigs Taggart}}
* {{jira|WEB-87}} - Votes: 4 - Land Store Map is not Updating - {{User|Gigs Taggart}}
* {{jira|VWR-505}} - Votes: 5 - Alpha-sorting of prims reversed, causing 'solid, non-alpha' prims to disappear. - {{User|beatfox xevious}}
* {{jira|SVC-128}} - Votes: 1 - automatic deletion of group leaves any owned property in "limbo" - {{User|Ahzzmandius Werribee}}
* {{jira|SVC-130}} - Votes: 3 - CC needed with PayPal, contradictory to what sl website says - {{User|3dziggy oh}}
** should be moved to WEB
** PayPal page, when invoked by [https://secondlife.com/account/billing.php SL.com's billing page], reacts different than what the billing page makes you expect.
*** -- [[User:Boroondas Gupte|Boroondas Gupte]] 14:18, 27 August 2007 (PDT)
* {{jira|SVC-131}} - Votes: 0 - Physical objects set to slow velocity sometimes stop - {{User|Ralph Doctorow}}
* {{jira|SVC-132}} - Votes: 1 - Setting vehicle buoyancy to very close to neutral stops slow moving vehicles - {{User|Ralph Doctorow}}
* {{jira|VWR-509}} - Votes: 1 - Renamed snaphots return to the default name Snapshot - {{User|Lisa Lowe}}
* {{jira|WEB-92}} - Votes: 0 - "Last Visit" Timestamp Bug - {{User|ViktorScorich Villota}}
* {{jira|WEB-94}} - Votes: 0 - credit card details that have been used for 3 years are now unauthorized - {{User|Fau Ferdinand}}
* {{jira|SVC-139}} - Votes: 0 - llOwnerSay-messages arrive in wrong order - {{User|Homer Horwitz}}
* {{jira|VWR-528}} - Votes: 3 - llSetScale fails on Flexi Objects - {{User|Rifkin Habsburg}}
* {{jira|SVC-141}} - Votes: 1 - Restrict Pushing disallows pushes from objects set to group - {{User|Lex Neva}}
* {{jira|MISC-150}} - Votes: 2 - When a child prim moves with llSetPos, any avatar sitting on it does not move. - {{User|Gigs Taggart}}
* {{jira|VWR-545}} - Votes: 3 - Controls freeze / inventry incomplete / Menus freeze / avatar wrong sex! - {{User|ratus raymaker}}

== Pre-meeting activity ==

Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.

=== Imported ===

=== Resolved ===

== Transcript ==
Transcript is/will be at [[{{PAGENAME}}/Transcript]]

{{Bug List Instructions}}

Alternate viewers

2007-08-31T19:49:48Z

Dale Glass: Added logging feature

== Introduction ==

The [[Extended_FAQ|Extended FAQ]] states that it is okay to create and distribute homebrew viewers as long they adhere to the respective licenses for code usage and server usage.

The code itself is licensed under {{OSWebsite|gplv2|alt=the GNU General Public License (GPL)}}, which governs modification and redistribuition of the source code. Use of Linden Lab's servers will still be governed by [http://secondlife.com/corporate/tos.php the Second Life Terms of Service]].

'''Homebrew viewers are obviously not associated with LindenLab, are governed by their own respective licenses. LindenLab is not responsible for any desired or undesired results in association with those viewers.'''

''Note to authors: If you make a viewer available make sure to include platform, version numbers and dates.''

 
 
 

== Official Linden Lab Viewer ==

=== Description ===

This viewer is the official version from LindenLab.

=== Links ===
* Website: [http://www.secondlife.com/ Second Life]
* Downloads: [http://secondlife.com/community/downloads.php LindenLab download page]
* Source code: [[Get_source_and_compile]]

 
 
 

== Able Edition ==

=== Description ===

This is a Windows viewer is an unofficial build which adds a [https://jira.secondlife.com/browse/VWR-1017 Mute Visibility] feature, which allows objects in-world to be rendered partially or entirely invisible.

=== Extra Features ===
* Mute Visibility
* Improvements to the Mute List
* Muting objects applies to entire linksets

=== Links ===
* Website: [http://ablewhitman.blogspot.com/ Able Whitman on Blogspot]
* Direct download link: http://ablewhitman.org/viewer/
* Source code: http://ablewhitman.org/viewer/

 
 
 

== Dale Glass Edition ==

=== Description ===

This is a Windows (soon Linux) viewer which adds new experimental features. The features are intended to give users more information about the world and to simplify moderation by making it easier to tell where people are and what they're doing.

=== Extra Features ===
* Avatar Scanner
** Shows nearby avatars, roughly in drawing distance range.
** Shows name, age, payment info, current activity.
** Land and estate commands for ejecting/banning multiple avatars at once
** Integration with Luskwood moderation tools
** Buttons to open profile, IM, teleport to or track selected avatars
* Event Log: Experimental feature, shows a list of active particle effects (soon sounds too), and their owners. Allows moving camera to emitter.
* Branding: Replaces LL branding with my own. Different login page, checks for updates against my server.
* Logging of the owner and location of speaking objects

=== Links ===
* Website: http://sl.daleglass.net
* Blog: http://daleglass.wordpress.com
* Direct download link: http://sl.daleglass.net/download
* Source code: http://svn.daleglass.net/sl/release/ ( [[User:Dale_Glass#Subversion_Repository|subversion]] )
 
 
 

== Nicholaz Edition ==

=== Description ===

This is a Windows viewer based on SL builds with various preliminary bug fix patches applied. Nonetheless it is of course an unofficial build. See [http://www.blueflash.cc/users/nicholaz/!!Installation.txt Installation.txt], [http://www.blueflash.cc/users/nicholaz/!Changes.txt Changes.txt] for more information.

=== Extra Features ===
* Particle system improved
* Different memory management for image list
* Many patches from the bug tracker which are not yet in the official viewer
* Old style GUI and GUI redesigns for the voice viewer

=== Links ===
* Website: [http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford on Blogspot]
* Direct download link: [http://www.blueflash.cc/users/nicholaz Download versions of this viewer]
* Source code: Look at the download site for the source-xxx-zip archive

 
 
 

User:Dale Glass

2007-08-30T22:12:19Z

Dale Glass: log_object_owners branch

Evil Scripter and RL programmer.

Currently working on adding an avatar scanner to the SL client.

= Projects =
== Avatar Scanner ==
http://daleglass.net/images/screenshots/avlist6_001.jpg

Features:
* Shows a list of all avatars known to the client. This can be easily more than a standard 96m scanner, and seems to depend on rendering distance.

* Keeps an internal list of avatars, and continues showing avatars that disappeared in the list for several seconds to give people time to perform some action on them (intended to make it easier to deal with griefers that do something nasty, then teleport out)

* Shows Linden accounts in bold. This will be expanded later to highlight people who are very new, don't have a credit card on file, etc depending on user configuration.

* Allows easy access to IM, profiles, etc

* Allows to start a conference to multiple avatars around you, the same way it works in the friends list.

* Allows tracking an avatar by placing a beacon on it. In the case the selected avatar isn't a friend who gave map location permission, it works anyway by placing a beacon on the avatar's last known position. This of course only works so long the avatar being tracked is near enough to be seen by the user.

* Automatically retrieves the birth date, account type and payment data for all users shown. The data is of course cached, and if this is too much of an extra load, I'll implement a permanent on-disk cache. If data doesn't arrive, it will retry with an exponential backoff (starting from 1 minute, doubling until 30 minutes)

* Displays activity status: new, left the area, emitting particles, moving, playing sound

* Allows moving the camera to the avatar with a double click, as well as cycling the camera between all or only the marked avatars

* Partial TrustNet integration: retrieves scores, but can't rate yet

What is not done yet, but will be:

* Integration with my TrustNet system. See here for details:
http://daleglass.net/tikiwiki/tiki-index.php?page=TrustNetAvatarScanner
http://daleglass.net/tikiwiki/tiki-index.php?page=HowTrustNetWorks

* Integration with resident-run databases. For example, I've been asked whether I could make it automatically query a website with a database of buyers to be able to tell people who are using avatars made with copybot, for instance.

* Buttons for administrative actions such as ban/eject/freeze/etc

* Add activity status for typing and rezzing objects

* Also longer term, option to make the client stop rendering an avatar completely.

'''Status''': Beta

'''SVN Repository''': http://svn.daleglass.net/sl/branches/avatarscanner

== TrustNet Integration ==
With the disappearance of SL ratings, I'm working on a replacement based on my TrustNet system. Current status is very experimental but with some functional code.

Here's a [http://daleglass.net/images/screenshots/trustnet_001.jpg screenshot] of what it looks like.

'''Status''': Alpha

'''SVN Repository''': http://svn.daleglass.net/sl/branches/trustnet

== Viewer/Script Communication ==
This is a hack to let a script talk to the viewer.

'''Status''': Stable

'''SVN Repository''': http://svn.daleglass.net/sl/branches/viewercomm

== Keyboard Hack ==
This is a viewer hack to make it transmit every keypress as a message on a channel. Used to implement an in-world keyboard that shows the real keypresses while the user is typing. General usage is discouraged, as this multiplies by 20-50 times the amount of chat messages sent to the sim and LL probably wouldn't like this sort of thing to be used widely.

'''Status''': Stable, but needs cleaning up and improvements.

'''SVN Repository''': http://svn.daleglass.net/sl/branches/realkeyboard

= Scripts =

* http://daleglass.net/scripts/load_archive.pl -- Script for loading source archives into Subversion. See comments in the source for usage.

= Subversion Repository =
The repository is located at [http://svn.daleglass.net/sl/ svn.daleglass.net]

== Branches ==
Current branches are:
* '''buildfixes_1-18-0''': 1.18.0 source, plus small compilation changes, for building with gcc4 and VC++ 2005. No functional changes here. Adds my installer.
* '''realkeyboard''': Silly patch that sends each keypress on a channel. Used to create a keyboard in SL that reflects my real keypresses.
* '''viewercomm''': Viewer/object communication patch
* '''avatarscanner''': Avatar scanner patch
* '''trustnet''': Support for my reputation system
* '''branding''': Branding changes: Different menu bar color, send crash reports to daleglass.net
* '''release''': Merge of various branches. This is where my installers are made from.
* '''trunk''': Currently unused
* '''log_object_owners''': Show owners and location of speaking objects in chat history

== How to get a patch ==
People sometimes ask me if I have patches. Currently I don't make them, because you can easily create an up to date one. Here's how:

<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/<branch> > patch
</code>

For example, to get a patch with my avatar scanner:
<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/avatarscanner > avatar-scanner.patch
</code>

This will create a patch with the difference between my '''buildfixes''' branch and another. This should apply cleanly to pristine sources.

== Branch Graph ==
Some branches are fed changes from others. This graph shows the hierarchy.

[[Image:Daleglass branch graph.png]]

= Installer =
My '''release''' branch (see above) is periodically packaged into an installer. If you get this, have in mind this is completely unofficial and unsupported by Linden Lab. Don't report bugs you find in it to LL.

This version will try to send crash reports to me, and not to LL. Updates will be downloaded from my server as well.

== Windows ==
The latest installer can be found at [http://daleglass.net/installer/setup_latest.exe daleglass.net]

There's no autoupdate mechanism yet.

== Linux ==
I don't create Linux packages yet. You'll have to get the source from SVN and [[Compiling_the_viewer_(Linux) | build it]]

I may start making packages if there is demand.

== FreeBSD ==
I don't currently use BSD, so you'll have to get the source from SVN and [[Compiling_the_viewer_(FreeBSD) | build it]]

== OS X ==
I don't have any Mac hardware, so I can't create packages for it. I'm not currently planning to buy any either.

This means that Mac users will have to [[Compiling_the_viewer_(Mac_OS_X) | build it from source]], or get somebody to integrate my changes and create a package for them.

Despite this, anybody using it on a Mac is welcome to submit bug reports. If it's a Mac specific problem, I will appreciate information on how to fix it. The bug reporter will be expected to test the results for me, since I can't.

= Etc =
{{Jira Reporter}}

Alternate viewers

2007-08-30T13:54:56Z

Dale Glass: Added information on my viewer

== Introduction ==

The [[Extended_FAQ|Extended FAQ]] states that it is okay to create and distribute homebrew viewers as long they adhere to the respective licenses for code usage and server usage.

The code itself is licensed under {{OSWebsite|gplv2|alt=the GNU General Public License (GPL)}}, which governs modification and redistribuition of the source code. Use of Linden Lab's servers will still be governed by [http://secondlife.com/corporate/tos.php the Second Life Terms of Service]].

'''Homebrew viewers are obviously not associated with LindenLab, are governed by their own respective licenses. LindenLab is not responsible for any desired or undesired results in association with those viewers.'''

''Note to authors: If you make a viewer available make sure to include platform, version numbers and dates.''

 
 
 
== Official Linden Lab Viewer ==

=== Description ===

This viewer is the official version from LindenLab.

=== Links ===
* Website: [http://www.secondlife.com/ Second Life]
* Downloads: [http://secondlife.com/community/downloads.php LindenLab download page]
* Source code: [[Get_source_and_compile]]

 
 
 
== Nicholaz Edition ==

=== Description ===

This is a Windows viewer based on SL builds with various preliminary bug fix patches applied. Nonetheless it is of course an unofficial build. See [http://www.blueflash.cc/users/nicholaz/!!Installation.txt Installation.txt], [http://www.blueflash.cc/users/nicholaz/!Changes.txt Changes.txt] for more information.

=== Extra Features ===
* Particle system improved
* Different memory management for image list
* Many patches from the bug tracker which are not yet in the official viewer

=== Links ===
* Website: [http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford on Blogspot]
* Direct download link: [http://www.blueflash.cc/users/nicholaz Download versions of this viewer]
* Source code: Look at the download site for the source-xxx-zip archive

 
 
 

== Able Edition ==

=== Description ===

This is a Windows viewer is an unofficial build which adds a [https://jira.secondlife.com/browse/VWR-1017 Mute Visibility] feature, which allows objects in-world to be rendered partially or entirely invisible.

=== Extra Features ===
* Mute Visibility
* Improvements to the Mute List
* Muting objects applies to entire linksets

=== Links ===
* Website: [http://ablewhitman.blogspot.com/ Able Whitman on Blogspot]
* Direct download link: http://ablewhitman.org/viewer/
* Source code: http://ablewhitman.org/viewer/

== Dale Glass Edition ==

=== Description ===

This is a Windows (soon Linux) viewer which adds new experimental features. The features are intended to give users more information about the world and to simplify moderation by making it easier to tell where people are and what they're doing.

=== Extra Features ===
* Avatar Scanner
** Shows nearby avatars, roughly in drawing distance range.
** Shows name, age, payment info, current activity.
** Land and estate commands for ejecting/banning multiple avatars at once
** Integration with Luskwood moderation tools
** Buttons to open profile, IM, teleport to or track selected avatars
* Event Log: Experimental feature, shows a list of active particle effects (soon sounds too), and their owners. Allows moving camera to emitter.
* Branding: Replaces LL branding with my own. Different login page, checks for updates against my server.

=== Links ===
* Website: http://sl.daleglass.net
* Blog: http://daleglass.wordpress.com
* Direct download link: http://sl.daleglass.net/download
* Source code: http://svn.daleglass.net/sl/release/ ( [[User:Dale_Glass#Subversion_Repository|subversion]] )
 
 
 

Bug triage/2007-08-20

2007-08-20T02:14:02Z

Dale Glass: /* Misc Pool */

{{Bug triage}}

Next meeting: 2007-08-20 at 3pm. See [[Bug triage]] for details.

== Fast Track Import ==

(Move bugs here that have solid repros, or valid patches that you have reviewed)

== Hot by Vote ==

== Patches ==

== Misc Pool ==
* {{jira|SVC-481}} - 2 votes - permission sharing between scripts has been broken - [[User:Drew Dwi|Drew Dwi]]
* {{jira|SVC-82}} - 2 votes - RAW files don't upload or download property lines in channel #4 - [[User:mathieu basiat|mathieu basiat]]
* {{jira|MISC-94}} - 0 votes - Problem with video card X1950 - [[User:Dorian Bamaisin|Dorian Bamaisin]]
* {{jira|VWR-375}} - 1 votes - The chat text window is unresponsive on G5 Mac - [[User:StarSong Bright|StarSong Bright]]
* {{jira|VWR-380}} - 5 votes - Resized Flexible Prims Render Improperly - [[User:Khamon Fate|Khamon Fate]]
* {{jira|SVC-88}} - 2 votes - llSetRot set roation thru llSetPrimitiveParams causes prim to dirft. - [[User:gearsawe stonecutter|gearsawe stonecutter]]
* {{jira|VWR-395}} - 1 votes - HUD incomplete render - [[User:Threedee Shepherd|Threedee Shepherd]]
* {{jira|VWR-396}} - 0 votes - Crash message stating xpcom_core.dll is not found - [[User:Kittenanne Mousehold|Kittenanne Mousehold]]
* {{jira|VWR-403}} - 6 votes - llGetBoundingBox is off and getting worse - [[User:skidz tweak|skidz tweak]]
* {{jira|VWR-406}} - 0 votes - Cannot See Other Avatars When Using Voice Beta Build 109 - [[User:Jared Halleck|Jared Halleck]]
* {{jira|VWR-417}} - 3 votes - Avatar skins load twice - [[User:Eric Ruban|Eric Ruban]]
* {{jira|VWR-422}} - 3 votes - LSL scripts created on Mac with non-ASCII characters won't compile in Windows viewer - [[User:Simon Nolan|Simon Nolan]]
* {{jira|MISC-112}} - 0 votes - Attached Flexi Objects dither - [[User:Amalia Oumionna|Amalia Oumionna]]
* {{jira|SVC-106}} - 2 votes - Receiving IMs via email from object that has been deleted in-world - [[User:Simon Nolan|Simon Nolan]]
* {{jira|SVC-108}} - 2 votes - llUnsitAvatar command will work for anyone on any parcel if the avatar being unsat is sitting on the LAND (does not do this if they are on a Prim) - [[User:Traven Sachs|Traven Sachs]]
* {{jira|SVC-109}} - 0 votes - There is no way to safely serialize a list, a new function is needed. - [[User:Argent Stonecutter|Argent Stonecutter]]
* {{jira|VWR-433}} - 2 votes - Vivox-gw.exe crashes in Voice Beta after 5-10 minutes; voice chat does not work at all - [[User:Cory Edo|Cory Edo]]
* {{jira|VWR-437}} - 0 votes - Object description is modified just by opening the object editor dialog - [[User:Rita Cummings|Rita Cummings]]
* {{jira|SVC-116}} - 7 votes - llGetFreeMemory() doesn't work! - [[User:Haravikk Mistral|Haravikk Mistral]]
* {{jira|VWR-442}} - 1 votes - No warning when inviting a new owner - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|VWR-443}} - 0 votes - Share with group toggle grays out when checked on deeded objects. - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|SVC-118}} - 0 votes - Invitations to existing group members get sent, but have no effect - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|SVC-119}} - 1 votes - Titles do not update on Role Change - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|SVC-120}} - 0 votes - Objects -> Permissions -> Modify Rights -> affects Return ability - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|SVC-121}} - 7 votes - Share with group does not respect Role Limitation - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|SVC-122}} - 0 votes - Simulators stay online even when the CAPS server is down - [[User:Eddy Stryker|Eddy Stryker]]
* {{jira|MISC-123}} - 0 votes - Unable to paste text from user's text editor into SL notecard - [[User:Mr Greggan|Mr Greggan]]
* {{jira|VWR-454}} - 0 votes - Avatar Locks Up in Voice Beta Client - [[User:Jared Halleck|Jared Halleck]]
* {{jira|VWR-463}} - 4 votes - Blank is a pre-defined texture in client, but not in LSL - [[User:Ice Brodie|Ice Brodie]]
* {{jira|WEB-84}} - 2 votes - can't download beta grid access for linux - [[User:Yorzian Mahana|Yorzian Mahana]]
* {{jira|VWR-490}} - 3 votes - LOD algorithm broken? - [[User:Haravikk Mistral|Haravikk Mistral]]
* {{jira|VWR-492}} - 2 votes - Name or description change, of an attached object, is rolled back when object is detached - [[User:Gellan Glenelg|Gellan Glenelg]]
* {{jira|WEB-86}} - 1 votes - Transaction History Total Bug when paying self owned object - [[User:Gypsy Paz|Gypsy Paz]]
* {{jira|MISC-132}} - 1 votes - Missing character in email sent with llEmail - [[User:Simil Miles|Simil Miles]]
* {{jira|VWR-500}} - 3 votes - Searching inventory for "copy", "modify" etc brings up everything. - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|VWR-502}} - 4 votes - client crashes on quit - [[User:Lex Neva|Lex Neva]]
* {{jira|WEB-87}} - 3 votes - Land Store Map is not Updating - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|SVC-126}} - 6 votes - In world map image is not updating - [[User:Gigs Taggart|Gigs Taggart]]
* {{jira|VWR-505}} - 3 votes - Alpha-sorting of prims reversed, causing 'solid, non-alpha' prims to disappear. - [[User:beatfox xevious|beatfox xevious]]
* {{jira|SVC-233}} - 4 votes - Sim crash upon deletion of HTTP heavy object - [[User:otakup0pe neumann|otakup0pe neumann]]

== Pre-meeting activity ==

Some issues will be resolved in the course of building this agenda. Rather than deleting them from the proposed agenda, move the issue and associated discussion into the appropriate section below.

=== Imported ===

=== Resolved ===

== Transcript ==

At the conclusion of this meeting, the transcript is/will be at [[{{PAGENAME}}/Transcript]]

{{Bug List Instructions}}

Third Party Libraries

2007-08-08T00:29:11Z

Dale Glass: updated info on vivox libraries

{{OSWikiLearnBox}}
{| border="1" cellpadding="3"
|- style="background:#ffdead;"
!Library !! Version !! Description !! GPL-Compatible? || Covered under [http://secondlife.com/developers/opensource/flossexception FLOSS exception]?


|-valign="top"
![http://apr.apache.org/ Apache Portable Runtime ] || 1.2.8
|A set of C functions which provide a portable and consistent interface into operating system - or simply widely useful - functionality. We primarily use it for threading and socket i/o. This is actually three packages, apr, apr-util and apr-iconv.
|| No, Apache 2.0 license
|| Yes


|-valign="top"
![http://www.boost.org/ Boost] || 1.32.0
|A set of portable C++ libraries which provide a wide set of functionality. Used primarily for tokenization.
|| Yes, BSDish


|-valign="top"
![http://daniel.haxx.se/projects/c-ares/ c-ares] || 1.3.2
|Performs DNS requests and name resolves asynchronously. Used with libcurl to keep all HTTP operations async.
|| Yes, BSDish


|-valign="top"
![http://developer.nvidia.com/page/cg_main.html CG] || ??
|cg controls some visual effects. - NOT USED BY THE NORMAL CLIENT.
|| No, permissive license but forbids reverse engineering.
|| No


|-valign="top"
![http://sourceforge.net/projects/elfio/ ELFIO] || 1.0.3
|Enhanced stacktrace information on the Linux client.
|| Yes, LGPL


|-valign="top"
![http://expat.sourceforge.net/ Expat] || 1.95.8
|XML parser.
|| Yes, MIT


|-valign="top"
![http://www.fmod.org FMOD] || 3.75
|Audio engine and mp3 stream decoder
|| No, proprietary
|| No


|-valign="top"
![http://www.freetype.org/ FreeType] || 2.1.5
|Font engine.
|| Yes, dual licensed BSD/Advertising + GPL


|-valign="top"
![http://www.gtk.org/ Glib] || 2.0.7
|??
|| Yes, LGPL


|-valign="top"
![http://www.gtk.org/ GTK+] || 2.0.9
|'Native' UI components on the Linux client.
|| Yes, LGPL


|-valign="top"
![http://www.ijg.org/ jpeglib] || 6b
|JPEG decoder library.
|| Yes, BSD


|-valign="top"
![http://www.kakadusoftware.com/ KDU] || 5.2.1
|Kakadu (KDU) JPEG-2000 decoder library.
|| No, Proprietary


|-valign="top"
![http://curl.haxx.se/libcurl/ libcurl] || 7.16.0
|Handles moving data across the net in many different protocols. Used to GET/POST/PUT/DELETE web resources.
|| Yes, MIT


|-valign="top"
![http://www.libpng.org/pub/png/libpng.html libpng] || 1.2.18
|PNG image library.
|| [http://www.libpng.org/pub/png/src/libpng-LICENSE.txt BSD-like]


|-valign="top"
!libuuid || ??
|Generates UUIDs under Linux. Originally a part of the ext2fs filesystem. Also see lluuid.cpp for all platforms.
|| Yes, LGPL


|-valign="top"
![http://ubrowser.com/llmozlib.php llMozLib] || 1.8.0.9
|llMozLib handles rendering HTML in the viewer via an embedded Gecko ([http://www.mozilla.org/developer/ Mozilla]) engine.
|| Yes, MPL/GPL/LGPL Tri-license


|-valign="top"
![http://www.mesa3d.org/ Mesa] || 6.2.1
|Provides the required OpenGL headers under Linux.
|| Yes


|-valign="top"
![http://xiph.org/ogg/ OGG] || 1.0.3
|Audio control.
|| Yes, BSDish


|-valign="top"
![http://www.opengl.org/ OpenGL] || GLX
| 3D Graphics rendering engine.
|| No (see [http://www.xfree86.org/4.4.0/LICENSE3.html XFree86 License FAQ])


|-valign="top"
![http://www.openjpeg.org/ OpenJPEG] || 1.0
|An open-source JPEG-2000 library; a slower alternative to Kadaku. Used in the open source release
|| Yes, however one must beware of patents.


|-valign="top"
![http://www.openssl.org/ OpenSSL] || 0.9.7c
|Provides encryption for sensitive actions such as user login
|| No, advertising clauses.
|| Yes


|-valign="top"
![http://developer.apple.com/quicktime/ Quicktime] || 7.13
|Used to play in-world video clips on a prim.
|| No, Proprietary
|| No


|-valign="top"
![http://www.isc.org/index.pl?/sw/bind/ libresolv / libllresolv] || 9.4.1
|Linux only - libllresolv is simply a rebuild of the system libresolv.so as the latter is very often broken in various ways on Linux. [[Building libllresolv]].
|| Yes, BSD


|-valign="top"
![http://www.libsdl.org/index.php SDL] || 1.2.7
|The Simple DirectMedia Layer libraries are used for handling input and basic window/GL setup on the Linux client.
|| Yes


|-valign="top"
![http://www.microquill.com/smartheap/index.html Smartheap] || ??
|Memory allocation (Windows only malloc() replacement)
|| No, Proprietary, but entirely optional (easy to comment out)
|| No


|-valign="top"
![http://tut-framework.sourceforge.net/ TUT] || 2006-06-22
|Unit test framework based on the use of c++ meta template programming. Used to test LL libraries.
|| Yes, BSD


|-valign="top"
![http://xiph.org/vorbis/ Vorbis] || 1.1.2
|Audio control.
|| Yes


|-valign="top"
![http://xmlrpc-epi.sourceforge.net/ xmlrpc-epi] || 0.51
|Controls the XML-RPC protocol.
|| Yes, BSD


|-valign="top"
![http://www.zlib.net/ zlib] || 1.2.1
|zlib is a lossless data-compression library which is used for a variety of network i/o and file compression.
|| Yes, MIT-like
|}

= Redistribution =
Some files in the SL installation can't be freely redistributed. This means it's not possible to simply package and offer for download a modified viewer: some files '''must not''' be redistributed.

This page documents the licenses and redistribution requirements of various files used by the viewer.

== Windows ==
These are the files that need to be shipped with the Windows version

=== Runtime ===
Microsoft components. It's not yet know whether they're redistributable.

* dbghelp.dll: [http://msdn2.microsoft.com/EN-US/library/ms679294.aspx Redistributable]
* msvcp71.dll: C Runtime Library, redistributable
* msvcr71.dll: C Runtime Library, [http://msdn2.microsoft.com/en-us/library/abx4dbyh(vs.71).aspx Redistributable]

=== FMOD ===
FMOD sound library. Free for non-commercial projects. A commercial license will be needed for a commercial viewer.

From the README in the package:
The fmod.dll file may be redistributed without the authors prior permission,
and must remain unmodified. The use of dll 'static linking' tools that aim
to hide the fmod library are forbidden.

* fmod.dll: [http://www.fmod.org/fmodlicense.html Redistributable, free for non-commercial projects]

=== Mozilla ===
The Gecko engine is MPL/GPL/LGPL licensed, which makes it redistributable.

* app_settings/mozilla
* freebl3.dll
* gksvggdiplus.dll
* js3250.dll
* nspr4.dll
* nss3.dll
* nssckbi.dll
* plc4.dll,
* plds4.dll
* smime3.dll
* softokn3.dll
* ssl3.dll
* xpcom.dll
* xul.dll

=== Kakadu ===
JPEG2000 library. '''Not redistributable'''.
OpenJPEG is an alternative library that is redistributable (does it work on Windows?)

* llkdu.dll

=== OpenSSL ===
SSL library. Redistributable.

* libeay32.dll
* ssleay32.dll

=== Vivox ===
Vivox is the component that provides the voice functionality.

* SLVoice.exe: Voice daemon. '''Not redistributable'''
* SLVoiceAgent: Exact purpose unknown. '''Not redistributable'''
* alut.dll: OpenAL, by Creative Labs. Redistributable.
* ortp.dll: oRTP project, LGPL. Redistributable.
* srtp.dll: Secure RTP?
* vivoxsdk.dll: Vivox Communications API. '''Not redistributable'''
* wrap_oal.dll: OpenAL32 by Creative Labs. Redistributable.

=== Unknown Libraries ===
The purpose and licensing of these files is not known:

* tntk.dll: Probably Vivox related

Third Party Libraries

2007-08-07T21:33:05Z

Dale Glass: Added vivox, unknown libraries section

{{OSWikiLearnBox}}
{| border="1" cellpadding="3"
|- style="background:#ffdead;"
!Library !! Version !! Description !! GPL-Compatible? || Covered under [http://secondlife.com/developers/opensource/flossexception FLOSS exception]?


|-valign="top"
![http://apr.apache.org/ Apache Portable Runtime ] || 1.2.8
|A set of C functions which provide a portable and consistent interface into operating system - or simply widely useful - functionality. We primarily use it for threading and socket i/o. This is actually three packages, apr, apr-util and apr-iconv.
|| No, Apache 2.0 license
|| Yes


|-valign="top"
![http://www.boost.org/ Boost] || 1.32.0
|A set of portable C++ libraries which provide a wide set of functionality. Used primarily for tokenization.
|| Yes, BSDish


|-valign="top"
![http://daniel.haxx.se/projects/c-ares/ c-ares] || 1.3.2
|Performs DNS requests and name resolves asynchronously. Used with libcurl to keep all HTTP operations async.
|| Yes, BSDish


|-valign="top"
![http://developer.nvidia.com/page/cg_main.html CG] || ??
|cg controls some visual effects. - NOT USED BY THE NORMAL CLIENT.
|| No, permissive license but forbids reverse engineering.
|| No


|-valign="top"
![http://sourceforge.net/projects/elfio/ ELFIO] || 1.0.3
|Enhanced stacktrace information on the Linux client.
|| Yes, LGPL


|-valign="top"
![http://expat.sourceforge.net/ Expat] || 1.95.8
|XML parser.
|| Yes, MIT


|-valign="top"
![http://www.fmod.org FMOD] || 3.75
|Audio engine and mp3 stream decoder
|| No, proprietary
|| No


|-valign="top"
![http://www.freetype.org/ FreeType] || 2.1.5
|Font engine.
|| Yes, dual licensed BSD/Advertising + GPL


|-valign="top"
![http://www.gtk.org/ Glib] || 2.0.7
|??
|| Yes, LGPL


|-valign="top"
![http://www.gtk.org/ GTK+] || 2.0.9
|'Native' UI components on the Linux client.
|| Yes, LGPL


|-valign="top"
![http://www.ijg.org/ jpeglib] || 6b
|JPEG decoder library.
|| Yes, BSD


|-valign="top"
![http://www.kakadusoftware.com/ KDU] || 5.2.1
|Kakadu (KDU) JPEG-2000 decoder library.
|| No, Proprietary


|-valign="top"
![http://curl.haxx.se/libcurl/ libcurl] || 7.16.0
|Handles moving data across the net in many different protocols. Used to GET/POST/PUT/DELETE web resources.
|| Yes, MIT


|-valign="top"
![http://www.libpng.org/pub/png/libpng.html libpng] || 1.2.18
|PNG image library.
|| [http://www.libpng.org/pub/png/src/libpng-LICENSE.txt BSD-like]


|-valign="top"
!libuuid || ??
|Generates UUIDs under Linux. Originally a part of the ext2fs filesystem. Also see lluuid.cpp for all platforms.
|| Yes, LGPL


|-valign="top"
![http://ubrowser.com/llmozlib.php llMozLib] || 1.8.0.9
|llMozLib handles rendering HTML in the viewer via an embedded Gecko ([http://www.mozilla.org/developer/ Mozilla]) engine.
|| Yes, MPL/GPL/LGPL Tri-license


|-valign="top"
![http://www.mesa3d.org/ Mesa] || 6.2.1
|Provides the required OpenGL headers under Linux.
|| Yes


|-valign="top"
![http://xiph.org/ogg/ OGG] || 1.0.3
|Audio control.
|| Yes, BSDish


|-valign="top"
![http://www.opengl.org/ OpenGL] || GLX
| 3D Graphics rendering engine.
|| No (see [http://www.xfree86.org/4.4.0/LICENSE3.html XFree86 License FAQ])


|-valign="top"
![http://www.openjpeg.org/ OpenJPEG] || 1.0
|An open-source JPEG-2000 library; a slower alternative to Kadaku. Used in the open source release
|| Yes, however one must beware of patents.


|-valign="top"
![http://www.openssl.org/ OpenSSL] || 0.9.7c
|Provides encryption for sensitive actions such as user login
|| No, advertising clauses.
|| Yes


|-valign="top"
![http://developer.apple.com/quicktime/ Quicktime] || 7.13
|Used to play in-world video clips on a prim.
|| No, Proprietary
|| No


|-valign="top"
![http://www.isc.org/index.pl?/sw/bind/ libresolv / libllresolv] || 9.4.1
|Linux only - libllresolv is simply a rebuild of the system libresolv.so as the latter is very often broken in various ways on Linux. [[Building libllresolv]].
|| Yes, BSD


|-valign="top"
![http://www.libsdl.org/index.php SDL] || 1.2.7
|The Simple DirectMedia Layer libraries are used for handling input and basic window/GL setup on the Linux client.
|| Yes


|-valign="top"
![http://www.microquill.com/smartheap/index.html Smartheap] || ??
|Memory allocation (Windows only malloc() replacement)
|| No, Proprietary, but entirely optional (easy to comment out)
|| No


|-valign="top"
![http://tut-framework.sourceforge.net/ TUT] || 2006-06-22
|Unit test framework based on the use of c++ meta template programming. Used to test LL libraries.
|| Yes, BSD


|-valign="top"
![http://xiph.org/vorbis/ Vorbis] || 1.1.2
|Audio control.
|| Yes


|-valign="top"
![http://xmlrpc-epi.sourceforge.net/ xmlrpc-epi] || 0.51
|Controls the XML-RPC protocol.
|| Yes, BSD


|-valign="top"
![http://www.zlib.net/ zlib] || 1.2.1
|zlib is a lossless data-compression library which is used for a variety of network i/o and file compression.
|| Yes, MIT-like
|}

= Redistribution =
Some files in the SL installation can't be freely redistributed. This means it's not possible to simply package and offer for download a modified viewer: some files '''must not''' be redistributed.

This page documents the licenses and redistribution requirements of various files used by the viewer.

== Windows ==
These are the files that need to be shipped with the Windows version

=== Runtime ===
Microsoft components. It's not yet know whether they're redistributable.

* dbghelp.dll: [http://msdn2.microsoft.com/EN-US/library/ms679294.aspx Redistributable]
* msvcp71.dll: C Runtime Library, redistributable
* msvcr71.dll: C Runtime Library, [http://msdn2.microsoft.com/en-us/library/abx4dbyh(vs.71).aspx Redistributable]

=== FMOD ===
FMOD sound library. Free for non-commercial projects. A commercial license will be needed for a commercial viewer.

From the README in the package:
The fmod.dll file may be redistributed without the authors prior permission,
and must remain unmodified. The use of dll 'static linking' tools that aim
to hide the fmod library are forbidden.

* fmod.dll: [http://www.fmod.org/fmodlicense.html Redistributable, free for non-commercial projects]

=== Mozilla ===
The Gecko engine is MPL/GPL/LGPL licensed, which makes it redistributable.

* app_settings/mozilla
* freebl3.dll
* gksvggdiplus.dll
* js3250.dll
* nspr4.dll
* nss3.dll
* nssckbi.dll
* plc4.dll,
* plds4.dll
* smime3.dll
* softokn3.dll
* ssl3.dll
* xpcom.dll
* xul.dll

=== Kakadu ===
JPEG2000 library. '''Not redistributable'''.
OpenJPEG is an alternative library that is redistributable (does it work on Windows?)

* llkdu.dll

=== OpenSSL ===
SSL library. Redistributable.

* libeay32.dll
* ssleay32.dll

=== Vivox ===
Vivox is the component that provides the voice functionality. Redistribution status unknown.

* SLVoice.exe: Voice daemon
* SLVoiceAgent: Exact purpose unknown
* alut.dll
* ortp.dll
* srtp.dll
* vivoxsdk.dll: Vivox Communications API
* wrap_oal.dll: OpenAL32 by Creative Labs

=== Unknown Libraries ===
The purpose and licensing of these files is not known:

* tntk.dll: Probably Vivox

Build the Viewer on Linux

2007-08-04T23:59:25Z

Dale Glass: Fixed formatting

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

{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

= Building the client =
To build the Second Life Viewer you will first need to install the required tools and libraries.
The following sections outline steps to build the client from source. To simplify building,
Linden labs has been nice enough to prepackage some of the libraries and bundled them up in an
additional tar file.

And while The Second Life Viewer is not a trivial build, and experience with building large
software packages will help you greatly - but don't be daunted, it should be simple once the
dependencies are in the right place.

The tasks are:
# Install required tools.
# Unpack source and art tree's from Linden Labs.
# Install libraries not shiped by Linden Labs.
# Unpack or install the other required libraries and headers.
# Compile.
 
 
== Required tools ==
There are a number of tools that need to be installed first.

* SCons build tool [package: scons]
* GCC 3.4 C/C++ compiler
** [debian/ubuntu: g++-3.4]
** [fedora: compat-gcc-34-c++]
** other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without a few simple code adjustments. {link to them pls}
* yacc [suggest packages: bison]
* lex [suggest packages: flex]
 
 

== Unpack the source tree ==

You can get the source either from the source archives available at [[Source downloads]], or you can get it from [[Subversion]].

Using a source archive is the easier option, but if you plan to do active development and want to make your own modifications, while merging LL's changes, subversion will probably be much more convenient on the long term.

=== Getting the source from the source archives ===
Get the source from [[Source downloads]]. You will need all 3 archives: source, artwork and libraries.

Choose a location and unpack the source tree and the art work. They will be extracted into a
directory call linden.

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

=== Getting the source from Subversion ===
Select a source [[Source branches|branch]] to check out.

Check it out with:
<code>
% svn co http://svn.secondlife.com/svn/linden/<branch> [directory]
</code>
If you don't specify the directory, it'll use the name of the branch as the default.

Now you will have a directory with the source code. This only includes the source code itself, without the libraries or artwork. You will have to get them from the [[Source downloads]] and unpack them into the tree.

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:
<code>
% ln -sf <branch> linden
</code>

Now unpack the libraries and artwork:
<code>
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>

 

== Installing the required libraries (that Linden labs can not or does not provide)==
=== FMOD (audio) ===
* FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. 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
** Add FMOD=no to your Scons build command when compiling the source.
* If you want to use FMOD, fetch and unpack FMOD 3.75 <http://www.fmod.org/>
<code>
% wget http://www.fmod.org/files/fmodapi375linux.tar.gz
% tar -xzvf fmodapi375linux.tar.gz
% cd fmodapi375linux/
% cp api/inc/* ../linden/libraries/i686-linux/include/
% cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>
 
 

== Installing the required dependencies (prepackaged by Linden labs)==

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.
<code>
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>

If you choose to use the provided libraries you can skip to
[[Compiling_the_viewer_%28Linux%29#Compiling|Compiling the client]].
 
=== Doing yourself ===
If you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries. You will have to install the following additional dependencies
listed below. Paths and package names given here are based on Ubuntu 7.04 and may vary
according to your Linux distribution.

==== List of libraries ====
* apr-1 [ubuntu: libapr1-dev, fedora: apr-devel]

* aprutil-1 [ubuntu: libaprutil1-dev, fedora: apr-util-devel]

* boost [ubuntu: libboost-dev, fedora: boost-devel]

* boost-regex [ubuntu: libboost-regex-dev]

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

* ELFIO <http://sourceforge.net/projects/elfio/>
** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so
<code>
% cd ELFIO && g++-3.4 -shared *.o -o libelfio.so
</code>

* expat [ubuntu: libexpat1-dev, fedora: expat-devel]

* google-perftools library for the tcmalloc and stacktrace libraries. (memory checking)
**[ubuntu: libgoogle-perftools-dev, fedora: google-perftools-devel.i386

* GTK 2.x development headers [ubuntu: libgtk2.0-dev, fedora: gtk2-devel]

* jpeglib [ubuntu: libjpeg62-dev, fedora: libjpeg-devel]

* OpenGL development headers: gl.h, glext.h, glu.h
**[ubuntu: mesa-common-dev, libglu1-mesa-dev, fedora: mesa-libGL-devel, mesa-libGLU-devel]

* OpenJPEG <http://www.openjpeg.org/>
** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
*** ''what does this mean?''

* OpenSSL <http://www.openssl.org/> [ubuntu: ?, fedora: ?]

* SDL [ubuntu libsdl1.2-dev, fedora: SDL-devel]

* Vorbis [ubuntu: libvorbis-dev, fedora: libvorbis-devel]

* X11 development headers: Xlib.h, and Xutil.h
**[ubuntu: libx11-dev, fedora: libX11-devel]

* xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
** Apply patches from the instructions in [[patch xmlrpc-epi]]
*** ''does this still work?''
** See also:
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-gcc4.1.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-use-system-expat.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-rename.patch
*** You have to regenerate autotools after applying the patches:
****libtoolize -c -f
****aclocal
****automake -c -a -f
****autoconf
*** The first patch fixes compiling on gcc 4. The second patch causes it to compile against the system expat, the version xmlrpc-epi comes with is broken and will not work. The last patch renames the library from xmlrpc to xmlrpc-epi, otherwise it conflicts with xmlrpc-c - which means the viewer then needs to be patched to link against xmlrpc-epi and not xmlrpc. These patches are from my Fedora package. On linux, I recommend these patches in favor of the Linden ones, as theirs seem to be for windows. (And mine actually work)
 
 

==== Copy headers and libraries into the source tree ====

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.

If you are using the easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:

* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.

<code>
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include

cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

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

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

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>
 
 

== Compiling ==
=== Build Types ===
The ''BUILD'' parameter specifies the build type. For normal usage, use '''release'''. If you plan to work on the source, choose '''releasenoopt''' or '''debug''', as these versions are unoptimized and much easier to debug.

* '''release''': Optimized build for release.
* '''releasenoopt''': Unoptimized build.
* '''debug''': Debug build with assertions.
* '''releasefordownload''': Optimized build for release, will create a .tar.gz with the files for distribution.
 
=== Building ===
=== Disable llMozLib ===
Add MOZLIB=no to your Scons build command when compiling the source.
 
<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.
 
 
== 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. 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:
<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=../../libraries/i686-linux/lib_release_client:${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 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

==== Automated libraries and headers adjustments, compilation and packaging ====
 
Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.70 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

###############################################################################
# BEWARE: this script is meant to compile a -personal- SL client. It is -NOT- #
# suitable to build client versions meant for public release, because #
# non-open source code is packaged by this script (e.g. libkdu). #
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# The packaged build will be moved to your home directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro. Tested with SL v1.17 sources.

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

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
# Beware: libdb4 makes use of libapr... so you should keep USE_SYSTEM_APR
# and USE_SYSTEM_DB4 in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
# Enabling the system freetype2 prevents the client from using the SL fonts,
# or at least, this is what happens on my system (Mandrake 10.2 with PLF
# freetype2).
USE_SYSTEM_FREETYPE2="no"
USE_SYSTEM_PERFTOOLS="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp"
# BEWARE: because of a bug in the v1.17.2.0 SConstruct file, you MUST keep at
# least an -O2 flag in the TUNE_FLAGS, to avoid getting a very slooooow client...
# This problem was apparently fixed in v1.17.3.0.
TUNE_FLAGS="-fomit-frame-pointer -frename-registers -fweb -fexpensive-optimizations"

# Whether to build with the browser login screen or not:
WITH_MOZILLA="yes"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
if (($? == 0)) ; then
mv $PATH_TO_SOURCES/indra/newview/SecondLife*.tar.bz2 $HOME/
fi
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

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

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Check for patches to apply. The names of the patches must be in the form
# slviewer-*.patch* (Example: slviewer-v117-EmbbededNotecard.patch.bz2).
# They must be applicable from inside the source directory with the -p1
# option, i.e. they have been built from outside the source directory
# with a diff command such as:
# diff -urN linden/ linden-patched/ >slviewer-whatever.patch
# And they may be gzipped or bzipped.
PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch* 2>/dev/null`
if [ "$PATCHES" != "" ] ; then
echo "Applying patches..."
cd $PATH_TO_SOURCES
PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch*`
for i in $PATCHES; do
echo "Patch: $i"
if echo $i | grep ".gz" &>/dev/null ; then
gunzip -c $i | patch -p1 -s
elif echo $i | grep ".bz2" &>/dev/null ; then
bzcat $i | patch -p1 -s
else
patch -p1 -s <$i
fi
done
fi

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] && [ "$TEMP_BUILD_DIR" != "" ] && [ "$TEMP_BUILD_DIR" != "/" ] && [ "$TEMP_BUILD_DIR" != "." ] && [ "$TEMP_BUILD_DIR" != ".." ] && [ "$TEMP_BUILD_DIR" != "$HOME" ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

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

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

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

# Fix a bug in v1.17.1 and later SConstruct file, where some libraries are
# compiled as shared instead of static, and are yet not packaged, and where
# fmod can't be enabled for OPENSOURCE:
sed -e "s/create_dynamic_module(module=module, module_libs=module_libs)/create_static_module(module)/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
sed -e "s/enable_fmod = not opensource and/enable_fmod =/" $TEMP_BUILD_DIR/SConstruct >$PATH_TO_SOURCES/indra/SConstruct
rm -f $TEMP_BUILD_DIR/SConstruct

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-g -pipe/$TUNE_FLAGS -pipe/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
sed -e "s/# / /" $TEMP_BUILD_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
#mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
rm -f $TEMP_BUILD_DIR/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

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

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

# LL makes the assumption that a certain unicode true type font is installed
# on all Linux systems... which is of course wrong ! Let's check, and when
# this font is absent, replace the broken soft link with an empty file: this
# at least will prevent the viewer to issue many warnings about not being able
# to load the unicode.ttf font.
if ! [ -r $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf ] ; then
rm -f $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf
touch $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf
fi

compile
</nowiki>
</pre>
</code>
 
 

== FreeBSD ==

A list of patches is given for [[Compiling the viewer (FreeBSD)]].

= Submitting Patches =
This is probably far down the road, but if you make changes to the source and want to submit them, see the page about [[Submitting patches|submitting patches]].

Build the Viewer on Linux

2007-08-04T21:39:45Z

Dale Glass: Added instructions on message.xml

SLDev-Traffic 20

2007-07-18T07:30:13Z

Dale Glass: Updated installer source URL to the path in the repository. .zip file was temporary and now out of date.

{{SLDevTraffic}}

sldev-traffic no 20

sldev discussions through July 15, 2007

== Bugs or Improvements Suitable for Open Source Programmers ==
Nicholaz Beresford created issue {{JIRA|VWR-1577}}, a meta issue listing a great many bugs that could be tackled by open source developers. If you're interested in getting your feet wet in the viewer, but need a project idea, look no further!

== Crash on Some AMD Chips ==
A bug went out in 1.17.3 which caused the Windows viewer to crash on startup with some AMD CPUs, owing to {{JIRA|VWR-1610}}. sldev listmembers climbed all over the bug in a very active thread, helping to identify and push possible solutions for the problem. And that's why we love you. :)

== Should Sculpted Prim Textures Be Uncompressed? ==
Dale Glass suggested that sculpted prim textures, or 64x64 and smaller textures in general, could remain uncompressed. This would provide an incentive to use smaller textures, and would solve the artifacting problems that drive sculpted prim makers to try using unnecessarily large textures. There hasn't been a viewer patch for this to date, but it should be possible to at least crank the jpeg compression level on small textures.

Helping to prove the uncompressed/reduced compression image concept, John Hurliman created a couple libsecondlife-based utilities at [[Importprimscript]] and [[SLImageUpload]]. Linden Lab can't speak to the safety of code from external sources, but peer code reviews are entirely appropriate on the mailing list.

== Redistributing the Second Life Viewer ==
Dale Glass, in working toward producing an independent viewer distribution, created a [[Redistribution]] page, which Rob Linden has consolidated with the Third Party Library page. As with the above, this is also a good place to look if you want to help tackle proprietary dependencies, a common desire among open source developers.

Dale's current approach is to make a meta installer, which collects files from an official installation, and retrieves all available and freely-distributable files needed to complete the installation from his own site automatically. Currently the installer is working for Windows, and the source is at http://svn.daleglass.net/sl/branches/buildfixes_1-18-0/indra/newview/installers/windows-dale/ - as always, proceed with care!

== Reliable Message Delivery Over HTTP ==
Phoenix Linden posted a link to [[Reliable Message Delivery Over HTTP]]. Linden Lab are planning to open source their Certified HTTP implementation, and here you can read about that, and the efforts on reliable back-end communication.

As a reminder, if there are other portions of the servers which should be open sourced in advance of the entire network of servers, the list is a great place to ask.

== "Bogus" Triage ==
Laurent Laborde sparked an effort at finding bugs which could be trivially rejected. As an increasing number of residents dive in headfirst, filing first bugs before learning to search for existing issues or send appropriate items to support, more of this will be necessary. Matthew Shepherd and Gigs Taggart pitched in, and altogether a great number of issues were resolved. (Thanks!)

== JIRA and SLDev Fanclub ==
Laurent Laborde was impressed by much of JIRA, and ended up creating an in-world group called the "JIRA and SLDev Fanclub." Laurent was originally going to name the list something which might have made it difficult for Lindens to join, but this one's safe.

If you're keen to catch other sldevers in-world outside of Linden office hours, this could be a good way of doing so.

== Mute Visbility Progress ==
Able Whitman continues development on visibility muting, as described in {{JIRA|VWR-1017}}. Able has posted patches to the mailing list, as well as a built viewer. The patch is at http://ablewhitman.org/viewer/aw-41571.patch.zip

== Open Source Candidate Repository ==
Dzonatas Sol is posting builds of the viewer with various open source patches applied. This could be a good way of testing patches for developers who aren't able or willing to collect patches and create their own builds. Dzonatas invites direct mail (or presumably in-world contact?) from parties wishing to work with her.

== Updated Doxygen Docs ==
If you're not using Dale Glass' generated Doxygen docs... you should be!

Updated this week: http://doc.daleglass.net/index.html

== JIRA Pain - Less Slowness - Wiki, More ==

The JIRA is running much faster than before, although there's still room for improvement.

The wiki still needs love. You can follow developments at {{JIRA|WEB-223}}.

== The Hippos ==

Last but certainly not least - [http://blog.secondlife.com/2007/07/17/linden-lab-to-recognize-open-source-contributors/ The Hippos]! Normally threads get to settle into inactivity for a couple days before being summarized, but this seemed relevant and certainly of interest to many sldev-traffic readers. Head on over for a read, and consider nominating someone you respect. :)

Thanks for readin'!

User:Dale Glass

2007-07-15T18:07:25Z

Dale Glass: fixed link

Evil Scripter and RL programmer.

Currently working on adding an avatar scanner to the SL client.

= Projects =
== Avatar Scanner ==
http://daleglass.net/images/screenshots/avlist6_001.jpg

Features:
* Shows a list of all avatars known to the client. This can be easily more than a standard 96m scanner, and seems to depend on rendering distance.

* Keeps an internal list of avatars, and continues showing avatars that disappeared in the list for several seconds to give people time to perform some action on them (intended to make it easier to deal with griefers that do something nasty, then teleport out)

* Shows Linden accounts in bold. This will be expanded later to highlight people who are very new, don't have a credit card on file, etc depending on user configuration.

* Allows easy access to IM, profiles, etc

* Allows to start a conference to multiple avatars around you, the same way it works in the friends list.

* Allows tracking an avatar by placing a beacon on it. In the case the selected avatar isn't a friend who gave map location permission, it works anyway by placing a beacon on the avatar's last known position. This of course only works so long the avatar being tracked is near enough to be seen by the user.

* Automatically retrieves the birth date, account type and payment data for all users shown. The data is of course cached, and if this is too much of an extra load, I'll implement a permanent on-disk cache. If data doesn't arrive, it will retry with an exponential backoff (starting from 1 minute, doubling until 30 minutes)

* Displays activity status: new, left the area, emitting particles, moving, playing sound

* Allows moving the camera to the avatar with a double click, as well as cycling the camera between all or only the marked avatars

* Partial TrustNet integration: retrieves scores, but can't rate yet

What is not done yet, but will be:

* Integration with my TrustNet system. See here for details:
http://daleglass.net/tikiwiki/tiki-index.php?page=TrustNetAvatarScanner
http://daleglass.net/tikiwiki/tiki-index.php?page=HowTrustNetWorks

* Integration with resident-run databases. For example, I've been asked whether I could make it automatically query a website with a database of buyers to be able to tell people who are using avatars made with copybot, for instance.

* Buttons for administrative actions such as ban/eject/freeze/etc

* Add activity status for typing and rezzing objects

* Also longer term, option to make the client stop rendering an avatar completely.

'''Status''': Beta

'''SVN Repository''': http://svn.daleglass.net/sl/branches/avatarscanner

== TrustNet Integration ==
With the disappearance of SL ratings, I'm working on a replacement based on my TrustNet system. Current status is very experimental but with some functional code.

Here's a [http://daleglass.net/images/screenshots/trustnet_001.jpg screenshot] of what it looks like.

'''Status''': Alpha

'''SVN Repository''': http://svn.daleglass.net/sl/branches/trustnet

== Viewer/Script Communication ==
This is a hack to let a script talk to the viewer.

'''Status''': Stable

'''SVN Repository''': http://svn.daleglass.net/sl/branches/viewercomm

== Keyboard Hack ==
This is a viewer hack to make it transmit every keypress as a message on a channel. Used to implement an in-world keyboard that shows the real keypresses while the user is typing. General usage is discouraged, as this multiplies by 20-50 times the amount of chat messages sent to the sim and LL probably wouldn't like this sort of thing to be used widely.

'''Status''': Stable, but needs cleaning up and improvements.

'''SVN Repository''': http://svn.daleglass.net/sl/branches/realkeyboard

= Scripts =

* http://daleglass.net/scripts/load_archive.pl -- Script for loading source archives into Subversion. See comments in the source for usage.

= Subversion Repository =
The repository is located at [http://svn.daleglass.net/sl/ svn.daleglass.net]

== Branches ==
Current branches are:
* '''buildfixes_1-18-0''': 1.18.0 source, plus small compilation changes, for building with gcc4 and VC++ 2005. No functional changes here. Adds my installer.
* '''realkeyboard''': Silly patch that sends each keypress on a channel. Used to create a keyboard in SL that reflects my real keypresses.
* '''viewercomm''': Viewer/object communication patch
* '''avatarscanner''': Avatar scanner patch
* '''trustnet''': Support for my reputation system
* '''branding''': Branding changes: Different menu bar color, send crash reports to daleglass.net
* '''release''': Merge of various branches. This is where my installers are made from.
* '''trunk''': Currently unused

== How to get a patch ==
People sometimes ask me if I have patches. Currently I don't make them, because you can easily create an up to date one. Here's how:

<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/<branch> > patch
</code>

For example, to get a patch with my avatar scanner:
<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/avatarscanner > avatar-scanner.patch
</code>

This will create a patch with the difference between my '''buildfixes''' branch and another. This should apply cleanly to pristine sources.

== Branch Graph ==
Some branches are fed changes from others. This graph shows the hierarchy.

[[Image:Daleglass branch graph.png]]

= Installer =
My '''release''' branch (see above) is periodically packaged into an installer. If you get this, have in mind this is completely unofficial and unsupported by Linden Lab. Don't report bugs you find in it to LL.

This version will try to send crash reports to me, and not to LL. Updates will be downloaded from my server as well.

== Windows ==
The latest installer can be found at [http://daleglass.net/installer/setup_latest.exe daleglass.net]

There's no autoupdate mechanism yet.

== Linux ==
I don't create Linux packages yet. You'll have to get the source from SVN and [[Compiling_the_viewer_(Linux) | build it]]

I may start making packages if there is demand.

== FreeBSD ==
I don't currently use BSD, so you'll have to get the source from SVN and [[Compiling_the_viewer_(FreeBSD) | build it]]

== OS X ==
I don't have any Mac hardware, so I can't create packages for it. I'm not currently planning to buy any either.

This means that Mac users will have to [[Compiling_the_viewer_(Mac_OS_X) | build it from source]], or get somebody to integrate my changes and create a package for them.

Despite this, anybody using it on a Mac is welcome to submit bug reports. If it's a Mac specific problem, I will appreciate information on how to fix it. The bug reporter will be expected to test the results for me, since I can't.

= Etc =
{{Jira Reporter}}

User:Dale Glass

2007-07-15T01:10:15Z

Dale Glass: /* Installer */

Evil Scripter and RL programmer.

Currently working on adding an avatar scanner to the SL client.

= Projects =
== Avatar Scanner ==
http://daleglass.net/images/screenshots/avlist6_001.jpg

Features:
* Shows a list of all avatars known to the client. This can be easily more than a standard 96m scanner, and seems to depend on rendering distance.

* Keeps an internal list of avatars, and continues showing avatars that disappeared in the list for several seconds to give people time to perform some action on them (intended to make it easier to deal with griefers that do something nasty, then teleport out)

* Shows Linden accounts in bold. This will be expanded later to highlight people who are very new, don't have a credit card on file, etc depending on user configuration.

* Allows easy access to IM, profiles, etc

* Allows to start a conference to multiple avatars around you, the same way it works in the friends list.

* Allows tracking an avatar by placing a beacon on it. In the case the selected avatar isn't a friend who gave map location permission, it works anyway by placing a beacon on the avatar's last known position. This of course only works so long the avatar being tracked is near enough to be seen by the user.

* Automatically retrieves the birth date, account type and payment data for all users shown. The data is of course cached, and if this is too much of an extra load, I'll implement a permanent on-disk cache. If data doesn't arrive, it will retry with an exponential backoff (starting from 1 minute, doubling until 30 minutes)

* Displays activity status: new, left the area, emitting particles, moving, playing sound

* Allows moving the camera to the avatar with a double click, as well as cycling the camera between all or only the marked avatars

* Partial TrustNet integration: retrieves scores, but can't rate yet

What is not done yet, but will be:

* Integration with my TrustNet system. See here for details:
http://daleglass.net/tikiwiki/tiki-index.php?page=TrustNetAvatarScanner
http://daleglass.net/tikiwiki/tiki-index.php?page=HowTrustNetWorks

* Integration with resident-run databases. For example, I've been asked whether I could make it automatically query a website with a database of buyers to be able to tell people who are using avatars made with copybot, for instance.

* Buttons for administrative actions such as ban/eject/freeze/etc

* Add activity status for typing and rezzing objects

* Also longer term, option to make the client stop rendering an avatar completely.

'''Status''': Beta

'''SVN Repository''': http://svn.daleglass.net/sl/branches/avatarscanner

== TrustNet Integration ==
With the disappearance of SL ratings, I'm working on a replacement based on my TrustNet system. Current status is very experimental but with some functional code.

Here's a [http://daleglass.net/images/screenshots/trustnet_001.jpg screenshot] of what it looks like.

'''Status''': Alpha

'''SVN Repository''': http://svn.daleglass.net/sl/branches/trustnet

== Viewer/Script Communication ==
This is a hack to let a script talk to the viewer.

'''Status''': Stable

'''SVN Repository''': http://svn.daleglass.net/sl/branches/viewercomm

== Keyboard Hack ==
This is a viewer hack to make it transmit every keypress as a message on a channel. Used to implement an in-world keyboard that shows the real keypresses while the user is typing. General usage is discouraged, as this multiplies by 20-50 times the amount of chat messages sent to the sim and LL probably wouldn't like this sort of thing to be used widely.

'''Status''': Stable, but needs cleaning up and improvements.

'''SVN Repository''': http://svn.daleglass.net/sl/branches/realkeyboard

= Scripts =

* http://daleglass.net/scripts/load_archive.pl -- Script for loading source archives into Subversion. See comments in the source for usage.

= Subversion Repository =
The repository is located at [http://svn.daleglass.net/sl/ svn.daleglass.net]

== Branches ==
Current branches are:
* '''buildfixes_1-18-0''': 1.18.0 source, plus small compilation changes, for building with gcc4 and VC++ 2005. No functional changes here. Adds my installer.
* '''realkeyboard''': Silly patch that sends each keypress on a channel. Used to create a keyboard in SL that reflects my real keypresses.
* '''viewercomm''': Viewer/object communication patch
* '''avatarscanner''': Avatar scanner patch
* '''trustnet''': Support for my reputation system
* '''branding''': Branding changes: Different menu bar color, send crash reports to daleglass.net
* '''release''': Merge of various branches. This is where my installers are made from.
* '''trunk''': Currently unused

== How to get a patch ==
People sometimes ask me if I have patches. Currently I don't make them, because you can easily create an up to date one. Here's how:

<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/<branch> > patch
</code>

For example, to get a patch with my avatar scanner:
<code>
$ svn diff http://svn.daleglass.net/sl/branches/buildfixes_1-18-0 http://svn.daleglass.net/sl/branches/avatarscanner > avatar-scanner.patch
</code>

This will create a patch with the difference between my '''buildfixes''' branch and another. This should apply cleanly to pristine sources.

== Branch Graph ==
Some branches are fed changes from others. This graph shows the hierarchy.

[[Image:Daleglass branch graph.png]]

= Installer =
My '''release''' branch (see above) is periodically packaged into an installer. If you get this, have in mind this is completely unofficial and unsupported by Linden Lab. Don't report bugs you find in it to LL.

This version will try to send crash reports to me, and not to LL. Updates will be downloaded from my server as well.

== Windows ==
The latest installer can be found at [http://daleglass.net/installer/setup_latest.exe daleglass.net]

There's no autoupdate mechanism yet.

== Linux ==
I don't create Linux packages yet. You'll have to get the source from SVN and [[http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) | build it]]

I may start making packages if there is demand.

== FreeBSD ==
I don't currently use BSD, so you'll have to get the source from SVN and [[Compiling_the_viewer_(FreeBSD) | build it]]

== OS X ==
I don't have any Mac hardware, so I can't create packages for it. I'm not currently planning to buy any either.

This means that Mac users will have to [[Compiling_the_viewer_(Mac_OS_X) | build it from source]], or get somebody to integrate my changes and create a package for them.

Despite this, anybody using it on a Mac is welcome to submit bug reports. If it's a Mac specific problem, I will appreciate information on how to fix it. The bug reporter will be expected to test the results for me, since I can't.

= Etc =
{{Jira Reporter}}

User:Dale Glass

2007-07-15T00:57:46Z

Dale Glass:

User:Dale Glass

2007-07-15T00:57:19Z

Dale Glass: creating section

User:Dale Glass

2007-07-15T00:56:15Z

Dale Glass: /* Subversion Repository */

User:Dale Glass

2007-07-15T00:45:05Z

Dale Glass: /* Subversion Repository */

User:Dale Glass

2007-07-15T00:39:21Z

Dale Glass: creating section

File:Daleglass branch graph.png

2007-07-15T00:38:16Z

Dale Glass: Graph of the branches found on the [http://svn.daleglass.net/sl daleglass.net repository].

Graph of the branches found on the [http://svn.daleglass.net/sl daleglass.net repository].

Redistribution

2007-07-09T17:47:28Z

Dale Glass: Initial version

Some files in the SL installation can't be freely redistributed. This means it's not possible to simply package and offer for download a modified viewer: some files '''must not''' be redistributed.

This page documents the licenses and redistribution requirements of various files used by the viewer.

= Windows =
These are the files that need to be shipped with the Windows version

== Runtime ==
Microsoft components. It's not yet know whether they're redistributable.

* dbghelp.dll: [http://msdn2.microsoft.com/EN-US/library/ms679294.aspx Redistributable]
* msvcp71.dll: C Runtime Library, redistributable
* msvcr71.dll: C Runtime Library, [http://msdn2.microsoft.com/en-us/library/abx4dbyh(vs.71).aspx Redistributable]

== FMOD ==
FMOD sound library. Free for non-commercial projects. A commercial license will be needed for a commercial viewer.

From the README in the package:
The fmod.dll file may be redistributed without the authors prior permission,
and must remain unmodified. The use of dll 'static linking' tools that aim
to hide the fmod library are forbidden.

* fmod.dll: [http://www.fmod.org/fmodlicense.html Redistributable, free for non-commercial projects]

== Mozilla ==
The Gecko engine is MPL/GPL/LGPL licensed, which makes it redistributable.

* app_settings/mozilla
* freebl3.dll
* gksvggdiplus.dll
* js3250.dll
* nspr4.dll
* nss3.dll
* nssckbi.dll
* plc4.dll,
* plds4.dll
* smime3.dll
* softokn3.dll
* ssl3.dll
* xpcom.dll
* xul.dll

== Kakadu ==
JPEG2000 library. '''Not redistributable'''.
OpenJPEG is an alternative library that is redistributable (does it work on Windows?)

* llkdu.dll

User:Dale Glass

2007-07-02T17:56:44Z

Dale Glass: updated project list

User:Soft Linden/scratch

2007-06-29T15:23:23Z

Dale Glass: /* sldev Meeting Times */

== sldev Meeting Times ==

Add your SL name and mark the time slots (in Pacific/SLT) that are generally agreeable and available for developer meetings. Don't worry about breaking it down to specific days - I'm just looking for clusters here.

Name Weekday 6a 9a 12 15 18 21 Weekend 6a 9a 12 15 18 21
Soft Linden * * * * * * * * * * * *
Nick * * * * * * * *
John Hurliman * * * * * *
Able Whitman * * * * * * *
Jason Giglio * * * * * * * *
Boroondas Gupte * * * * * *
Dana Fagerstrom * * *
Alissa Sabre * * * * *
Dale Glass * * * * * * * * *

== Old Patches Possibly Wanting Love ==
sldev PATCH build fixes for gcc 4 
Olivier Blin blino at mandriva.com 
Mon Jan 8 17:56:35 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000026.html

sldev PATCH: Copy UUID pie menu item 
John Hurliman jhurliman at wsu.edu 
Sat Jan 13 01:56:11 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000094.html

sldev alternative os support? 
Todd T. Fries sl at email.fries.net 
Mon Jan 22 17:20:24 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000176.html

sldev OpenJPEG MAX_PATH issue 
David Fries david at fries.net 
Sat Jan 20 14:43:49 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000180.html

sldev Re: LLOctree crash (weird crash) 
Dylan Alex Simon dylan at dylex.net 
Wed Jan 24 18:36:22 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000232.html

sldev New First Look source code 
Ismail Dönmez ismail at pardus.org.tr 
Sat Feb 3 04:09:22 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000315.html

sldev OpenJPEG meta decode, Second Life patches 
David Fries david at fries.net 
Sun Feb 11 14:26:06 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000362.html

sldev jinclude.h ? 
David Fries david at fries.net 
Wed Feb 14 20:00:27 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000425.html

sldev Let xmlrpc-epi use already installedversion of expat. 
Guido guidoj at users.sourceforge.net 
Mon Feb 19 07:46:59 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000459.html

sldev Ubuntu Runtime Error SDL 
David Fries david at fries.net 
Tue Feb 27 21:00:24 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000672.html

SLDev-Traffic 17

2007-06-25T01:00:33Z

Dale Glass: Script was linked, not attached. The attachment on my post is a GPG signature

{{SLDevTraffic}}

sldev-traffic no 17

sldev discussions through June 22, 2007

== Source Releases ==
Anthony Foster (Linden) posted the 1.18.0.0 source tarballs, with gratitude from Rob Lanphier (Linden) for the speed at which it's been posted.

Right now, the Windlight source only exists in the SVN, and at least one list member reported problems building, owing to glh/glh_lindear missing from the headers.

== Cleaning Up the Linux Build Doc ==
Max Okumoto had a go at cleaning up the Linux build instructions, with Dale Glass further refining the documentation afterward. Bryan O'Sullivan (Linden) commented that he'd made changes to the SConstruct script that should make it easy to build without the bundled libraries. Look for this in a coming release - it will make the Linux build easier still.

== Less Like a Sieve, More Like an Old Bucket ==
Thew viewer's not leaking anywhere near so much as it used to, thanks in very large part to Nicholaz Beresford's cleanup work. Nicholaz [http://nicholaz-beresford.blogspot.com/2007/06/memory-leaksleftover-almost-completed.html posts about it] on his blog. There's little doubt that there will be more leakage in the future as Lindens race to make the kinds of radical changes that grow Second Life, but the closer the viewer stays to Nicholaz' new baseline, the better.

== JIRA Pain ==
For four weekends in a row, JIRA has gone into molasses mode, sometimes taking terribly long to load pages, sometimes going away entirely. Rob Lanphier (Linden) confirms that an upgrade is pending, but doesn't have a date.

Matthew Dowd points to a known JIRA issue that's fixed in the newest version, manifesting as a "docs out of order" message. Matthew created a JIRA about it at {{JIRA|https://jira.secondlife.com/browse/WEB-180}}, with Torley Linden asking for direct email with "WEB-180" in the subject line next time it surfaces.

== SVN Source Merging Script ==
Dale Glass posts a script for merging new versions of the source into a private SVN repository, linked from his [https://lists.secondlife.com/pipermail/sldev/2007-June/002462.html original post].

== SVK For Local SVN Staging, GIT, and More ==
Dale Glass posts a brief introduction to using subversion and svk, which allows many of the benefits of svn write status on a read-only repository. The page is at [[source version control]]. Dzonatas Sol and Paul Hampson sing the praises of git and git-svn as well, noting that Linus Torvalds has called git production-ready, although both note that a good GUI would be advantageous, wishing for TortoiseGIT. Here's hoping!

Paul Hampson links to [http://utsl.gen.nz/talks/git-svn/intro.html an introduction to git-svn] for former svn-svk users.

Further piling onto the discussion, Joshua Bell (Linden) mentions that Mercurial is similar to git, is cross-platform, and that there's a "tortoise-hg" project under way.

== The P Word ==
Tim Shephard raises the question of plugin issues again, linking to a recent [http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ Reuters article] on the subject. There was some discussion about how plugins could allow some tools that could increase user retention, but the thread quickly shifted into a discussion of the largest issues adversely affecting the Second Life user experience, the biggest of which wouldn't be solved by client side changes.

== Proper Constant Parsing and Lex/Yacc help ==
Thanks to Dzonatas Sol's input and another patch from Argent Stonecutter, LSL is no longer swallowing subtraction operations as oddly placed negative constants. With Monday's optional update, some of those silly long-standing syntax errors that most often pop up when subtracting in loop compares will be gone.

Argent Stonecutter followed up with a little more detail on how constant folding could be done while still respecting order of precedence when variables and constants were in the mix.

== Fontconfig ==
Alissa Sabre created a page with [[User:Alissa Sabre/Notes on fontconfig]], explaining what it is, why the viewer should or shouldn't use it, and going into additional detail on how it could be used in the viewer.

This could address a number of current font issues, however at present there hasn't been any follow-up discussion.

== CPU and GPU Statistics ==
Soft Linden posted a sample of all of the CPU and GPU strings returned by residents' viewers over a one week period. After some analysis, there was a consensus that the strings need additional detail in order to provide meaningful information about the ability of the various machines used to visit Second Life.

We're fully willing to accept any enhancements to CPU and GPU identification and run another round of data if it would be useful to sldev members.

== We've Got Patches ==
Nicholaz Beresford and Gigs Taggart both posted lists of new patches. From Nicholaz, {{JIRA|VWR-1294}} and {{JIRA|VWR-1296}}. From Gigs, a number all linked to [https://lists.secondlife.com/pipermail/sldev/2007-June/002431.html his post], five more, which I believe are all in the JIRA.

At least two of Gigs' are already in our internal maintenance branch, and should be in Monday's optional viewer update. Sardonyx Linden claimed both of Nicholaz's patches, and at least one was in within half an hour. Nicholaz said we were giving the WINE project a run for its money on the speed of that import. We're doing better, and we'll push to keep that up.

Thanks for patchin'!

LSL To Client Communication

2007-06-23T01:16:50Z

Dale Glass: general functionality

{{Open Source Portal}}

=Communication=
A mechanism is needed to allow LSL scripts to talk to the viewer in order to allow implementing some interesting functionality, such as viewer UI extensions that communicate with in-world objects, for instance. Viewer to LSL communication is easily possible, by making the viewer talk on a specific channel, or use XML RPC. This may not be ideal for all cases, but it's already doable without any modifications.

What needs work is LSL to Client communication, as there currently isn't any good method in the official client for that.

=Requirements=
A robust mechanism should satisfy these requirements:

# Scripts must be able to receive messages from the viewer (can be done already with chat and XML RPC)
# Scripts must be able to reply to the viewer
# It must be possible to communicate with multiple viewers at once without confusion
# Order of delivery must be guaranteed (chat messages currently can be reordered)
# Messages must be reliable

The hack below can satisfy requirements #1 to #3. Requirement #4 would require extra work (although it's doable) and is possibly best ignored, as LL mentioned the possibility of moving chat to TCP, which would automatically solve the issue.

Requirement #5 is mostly satisfied as data isn't lost, and the only problem may be with the viewer or the script disappearing, which can be dealt with by designing the proper protocol, if needed.

=Hack=
While there's no official solution, here's what I came up with for now:

* Client to LSL: Client speaks on a channel directly. Nothing special here.
* LSL to Client: Script uses llOwnerSay, with this format:

<pre><nowiki>
$VwrComm$VERSION$COMPONENT$DATA
</nowiki></pre>

Fields:
* VwrComm: Header, must be present
* VERSION: Protocol version
* COMPONENT: Component inside the viewer the message is for
* DATA: Data being sent. The format of the data isn't specified.

==Behavior==

This is how the current implementation handles the protocol:

# Message must come from an object. Normal chat doesn't trigger it
# String gets split by "$" and must have at least 4 tokens
# First token must be VwrComm
# Second token must be "0" (version number, this will change)
# Third token matches the name of a known component.

If requirements #1 to #3 aren't satisfied, the string is passed as-is, and the code doesn't suppress its display.

If requirement #4 isn't satisfied, the text won't appear on screen, but the code won't continue further either. A message will be logged in the viewer's log, saying that a message with the wrong version was received.

If requirement #5 isn't satisfied, display is also suppressed, and a message is also logged.

If all those requirements are satisfied, the data in the message is sent to the specified part of the viewer for futher processing.

==Example==

<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

==Implementation==
Code for this can be found at [http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp], line 2047

Note that at the time of writing, the client isn't capable of telling the difference between object speech sent to all users (llSay/etc) and object speech sent only to the owner (llOwnerSay). It also doesn't check the speaking object's key or its owner's. This code must be fixed to obtain that information, so that the viewer can ignore messages from objects not owned by the user, when such a thing is necessary.

=Protocol=
The above describes the system and format for exchanging data. However, there are still a few problems to solve:

# Multiple extensions to the viewer must be able to coexist, without conflicting with others
# Viewer may not implement this at all, in which case the messages get displayed on screen
# Viewer replies to the script have potential security issues

Proposed solutions:

# See next section
# The LSL script initiates the conversation. It sends a single request and waits for a reply. This ensures that non-supporting clients don't get flooded with protocol data.
# During the establishment of the connection, the script chooses a random channel to listen on, and tells it to the viewer. This makes it very improbable that somebody will be able to intercept the data, as the channel will be different every time. An additional advantage is that there's no need to keep track of who uses what channel: the chance of a collision should be extremely low.

== Component Naming ==
The COMPONENT field of the protocol specifies the name of the component inside the viewer the script wants to talk to. The data is an arbitrary ASCII string, which may not contain newlines or the $ character. The proposed format is "AvatarName.FunctionName", where AvatarName is the first and last names of the avatar who created the functionality concatenated without a space, a period, and the name of the avatar's creation. This system should ensure that should two people come up with different ways to do the same thing, the COMPONENT names won't clash.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

== Connection Establishment ==
As described above, the LSL script initiates the communication by telling the viewer what channel it wants to talk on.

=== Connection Request ===
* The COMPONENT field's value is "DaleGlass.Viewer"
* The payload is "Connect$<channel>"

The fields are as follows:
* <channel> is the channel the script wants to talk on. For security, this SHOULD be randomly generated.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.Viewer$Connect$12421
</nowiki></pre>

=== Viewer Reply ===
Viewer replies to the request by sending the message "OK" to the specified channel. Any other reply MUST be considered an error message.

After this, any further requests to the viewer from the object are replied to in on the specified channel.

=== Example ===
<pre><nowiki>
integer g_channel = 0; // Channel to talk on -- randomly generated
integer g_listen_handle = 0; // Listen handle

integer g_timeout = 30; // How long to wait for the viewer to reply

ViewerComm(string component, string data) {
llOwnerSay("$VwrComm$0$" + component + "$" + data);
}

default {
state_entry() {
// Generate a random channel number
g_channel = (integer)(llFRand(4294967295) - 2147483648);

// Set a timer in case the viewer doesn't reply
llSetTimerEvent(g_timeout);

// Listen for replies
g_listen_handle = llListen(g_channel, "", llGetOwner(), "");

// Send connection request
ViewerComm("DaleGlass.Viewer", "Connect$" + (string)channel);
}

timer() {
llListenRemove(g_listen_handle);
llOwnerSay("Client/Viewer connection timed out -- probably not supported");
}

listen( integer channel, string name, key id, string message ) {
if ( message == "OK" ) {
// Connection successful
llOwnerSay("Client/Viewer connection successful");
} else {
// Something went wrong
llOwnerSay("Client/Viewer connection error: " + message);
}
}
}
</nowiki></pre>

= General Functionality =
This is the proposed functionality that would be implemented by the main patch itself, and supported by all viewers that speak this protocol. The idea is to provide some simple and generally useful functionality. All of them would use COMPONENT "DaleGlass.Viewer".

== GetViewerVersion ==
This command would return the viewer's version as a string, with the following format:
<pre><nowiki>
<major>$<minor>$<revision>$<build>
</nowiki></pre>

For example, viewer version 1.17.0 (12) would be sent as:
<pre><nowiki>
1$17$0$12
</nowiki></pre>

== GetViewerBuilder ==
Returns the name of the person who built the viewer. "Linden Lab" would be reserved for LL. My viewer would say "Dale Glass" here for instance.

== GetViewerRevision ==
Returns the viewer's revision number. This would apply only to custom built viewers. The recommendation is that the reply to this message be the revision number from the builder's source repository.

== GetExtensionList ==
Returns the list of supported viewer extensions, as a comma separated string. MUST NOT contain anything that'd conflict with llCSV2List.

Example reply:
<pre><nowiki>
DaleGlass.Viewer, DaleGlass.AvatarScanner, ExampleAvatar.CoolScript
</nowiki></pre>

The intention behind this command is allowing scripts that are capable of using multiple extensions determine which are present.

== GetOperatingSystem ==
Returns a string describing the OS being used:
* Linux
* Windows
* OS X
* Solaris
* (etc)

The intention is to allow scripts to determine that some functionality isn't available because the implementation is OS-specific. This MUST NOT be used as a primary method of detecting whether some functionality is supported (as this could change). Instead, this should only be used after GetExtensionList fails to return the desired functionality, and used to determine whether the lack of it is because it's not available on that OS at all.

[[Category:Design Discussions]]

LSL To Client Communication

2007-06-23T00:57:25Z

Dale Glass: formatting changes

{{Open Source Portal}}

=Communication=
A mechanism is needed to allow LSL scripts to talk to the viewer in order to allow implementing some interesting functionality, such as viewer UI extensions that communicate with in-world objects, for instance. Viewer to LSL communication is easily possible, by making the viewer talk on a specific channel, or use XML RPC. This may not be ideal for all cases, but it's already doable without any modifications.

What needs work is LSL to Client communication, as there currently isn't any good method in the official client for that.

=Requirements=
A robust mechanism should satisfy these requirements:

# Scripts must be able to receive messages from the viewer (can be done already with chat and XML RPC)
# Scripts must be able to reply to the viewer
# It must be possible to communicate with multiple viewers at once without confusion
# Order of delivery must be guaranteed (chat messages currently can be reordered)
# Messages must be reliable

The hack below can satisfy requirements #1 to #3. Requirement #4 would require extra work (although it's doable) and is possibly best ignored, as LL mentioned the possibility of moving chat to TCP, which would automatically solve the issue.

Requirement #5 is mostly satisfied as data isn't lost, and the only problem may be with the viewer or the script disappearing, which can be dealt with by designing the proper protocol, if needed.

=Hack=
While there's no official solution, here's what I came up with for now:

* Client to LSL: Client speaks on a channel directly. Nothing special here.
* LSL to Client: Script uses llOwnerSay, with this format:

<pre><nowiki>
$VwrComm$VERSION$COMPONENT$DATA
</nowiki></pre>

Fields:
* VwrComm: Header, must be present
* VERSION: Protocol version
* COMPONENT: Component inside the viewer the message is for
* DATA: Data being sent. The format of the data isn't specified.

==Behavior==

This is how the current implementation handles the protocol:

# Message must come from an object. Normal chat doesn't trigger it
# String gets split by "$" and must have at least 4 tokens
# First token must be VwrComm
# Second token must be "0" (version number, this will change)
# Third token matches the name of a known component.

If requirements #1 to #3 aren't satisfied, the string is passed as-is, and the code doesn't suppress its display.

If requirement #4 isn't satisfied, the text won't appear on screen, but the code won't continue further either. A message will be logged in the viewer's log, saying that a message with the wrong version was received.

If requirement #5 isn't satisfied, display is also suppressed, and a message is also logged.

If all those requirements are satisfied, the data in the message is sent to the specified part of the viewer for futher processing.

==Example==

<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

==Implementation==
Code for this can be found at [http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp], line 2047

Note that at the time of writing, the client isn't capable of telling the difference between object speech sent to all users (llSay/etc) and object speech sent only to the owner (llOwnerSay). It also doesn't check the speaking object's key or its owner's. This code must be fixed to obtain that information, so that the viewer can ignore messages from objects not owned by the user, when such a thing is necessary.

=Protocol=
The above describes the system and format for exchanging data. However, there are still a few problems to solve:

# Multiple extensions to the viewer must be able to coexist, without conflicting with others
# Viewer may not implement this at all, in which case the messages get displayed on screen
# Viewer replies to the script have potential security issues

Proposed solutions:

# See next section
# The LSL script initiates the conversation. It sends a single request and waits for a reply. This ensures that non-supporting clients don't get flooded with protocol data.
# During the establishment of the connection, the script chooses a random channel to listen on, and tells it to the viewer. This makes it very improbable that somebody will be able to intercept the data, as the channel will be different every time. An additional advantage is that there's no need to keep track of who uses what channel: the chance of a collision should be extremely low.

== Component Naming ==
The COMPONENT field of the protocol specifies the name of the component inside the viewer the script wants to talk to. The data is an arbitrary ASCII string, which may not contain newlines or the $ character. The proposed format is "AvatarName.FunctionName", where AvatarName is the first and last names of the avatar who created the functionality concatenated without a space, a period, and the name of the avatar's creation. This system should ensure that should two people come up with different ways to do the same thing, the COMPONENT names won't clash.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

== Connection Establishment ==
As described above, the LSL script initiates the communication by telling the viewer what channel it wants to talk on.

=== Connection Request ===
* The COMPONENT field's value is "DaleGlass.Viewer"
* The payload is "Connect$<channel>"

The fields are as follows:
* <channel> is the channel the script wants to talk on. For security, this SHOULD be randomly generated.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.Viewer$Connect$12421
</nowiki></pre>

=== Viewer Reply ===
Viewer replies to the request by sending the message "OK" to the specified channel. Any other reply MUST be considered an error message.

After this, any further requests to the viewer from the object are replied to in on the specified channel.

=== Example ===
<pre><nowiki>
integer g_channel = 0; // Channel to talk on -- randomly generated
integer g_listen_handle = 0; // Listen handle

integer g_timeout = 30; // How long to wait for the viewer to reply

ViewerComm(string component, string data) {
llOwnerSay("$VwrComm$0$" + component + "$" + data);
}

default {
state_entry() {
// Generate a random channel number
g_channel = (integer)(llFRand(4294967295) - 2147483648);

// Set a timer in case the viewer doesn't reply
llSetTimerEvent(g_timeout);

// Listen for replies
g_listen_handle = llListen(g_channel, "", llGetOwner(), "");

// Send connection request
ViewerComm("DaleGlass.Viewer", "Connect$" + (string)channel);
}

timer() {
llListenRemove(g_listen_handle);
llOwnerSay("Client/Viewer connection timed out -- probably not supported");
}

listen( integer channel, string name, key id, string message ) {
if ( message == "OK" ) {
// Connection successful
llOwnerSay("Client/Viewer connection successful");
} else {
// Something went wrong
llOwnerSay("Client/Viewer connection error: " + message);
}
}
}
</nowiki></pre>

[[Category:Design Discussions]]

LSL To Client Communication

2007-06-23T00:54:07Z

Dale Glass: More details, example script

{{Open Source Portal}}

=Communication=
A mechanism is needed to allow LSL scripts to talk to the viewer in order to allow implementing some interesting functionality, such as viewer UI extensions that communicate with in-world objects, for instance. Viewer to LSL communication is easily possible, by making the viewer talk on a specific channel, or use XML RPC. This may not be ideal for all cases, but it's already doable without any modifications.

What needs work is LSL to Client communication, as there currently isn't any good method in the official client for that.

=Requirements=
A robust mechanism should satisfy these requirements:

# Scripts must be able to receive messages from the viewer (can be done already with chat and XML RPC)
# Scripts must be able to reply to the viewer
# It must be possible to communicate with multiple viewers at once without confusion
# Order of delivery must be guaranteed (chat messages currently can be reordered)
# Messages must be reliable

The hack below can satisfy requirements #1 to #3. Requirement #4 would require extra work (although it's doable) and is possibly best ignored, as LL mentioned the possibility of moving chat to TCP, which would automatically solve the issue.

Requirement #5 is mostly satisfied as data isn't lost, and the only problem may be with the viewer or the script disappearing, which can be dealt with by designing the proper protocol, if needed.

=Hack=
While there's no official solution, here's what I came up with for now:

* Client to LSL: Client speaks on a channel directly. Nothing special here.
* LSL to Client: Script uses llOwnerSay, with this format:

<pre><nowiki>
$VwrComm$VERSION$COMPONENT$DATA
</nowiki></pre>

Fields:
* VwrComm: Header, must be present
* VERSION: Protocol version
* COMPONENT: Component inside the viewer the message is for
* DATA: Data being sent. The format of the data isn't specified.

===Behavior===

This is how the current implementation handles the protocol:

# Message must come from an object. Normal chat doesn't trigger it
# String gets split by "$" and must have at least 4 tokens
# First token must be VwrComm
# Second token must be "0" (version number, this will change)
# Third token matches the name of a known component.

If requirements #1 to #3 aren't satisfied, the string is passed as-is, and the code doesn't suppress its display.

If requirement #4 isn't satisfied, the text won't appear on screen, but the code won't continue further either. A message will be logged in the viewer's log, saying that a message with the wrong version was received.

If requirement #5 isn't satisfied, display is also suppressed, and a message is also logged.

If all those requirements are satisfied, the data in the message is sent to the specified part of the viewer for futher processing.

===Example===

<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

===Implementation===
Code for this can be found at [http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp], line 2047

Note that at the time of writing, the client isn't capable of telling the difference between object speech sent to all users (llSay/etc) and object speech sent only to the owner (llOwnerSay). It also doesn't check the speaking object's key or its owner's. This code must be fixed to obtain that information, so that the viewer can ignore messages from objects not owned by the user, when such a thing is necessary.

==Protocol==
The above describes the system and format for exchanging data. However, there are still a few problems to solve:

# Multiple extensions to the viewer must be able to coexist, without conflicting with others
# Viewer may not implement this at all, in which case the messages get displayed on screen
# Viewer replies to the script have potential security issues

Proposed solutions:

# See next section
# The LSL script initiates the conversation. It sends a single request and waits for a reply. This ensures that non-supporting clients don't get flooded with protocol data.
# During the establishment of the connection, the script chooses a random channel to listen on, and tells it to the viewer. This makes it very improbable that somebody will be able to intercept the data, as the channel will be different every time. An additional advantage is that there's no need to keep track of who uses what channel: the chance of a collision should be extremely low.

=== Component Naming ===
The COMPONENT field of the protocol specifies the name of the component inside the viewer the script wants to talk to. The data is an arbitrary ASCII string, which may not contain newlines or the $ character. The proposed format is "AvatarName.FunctionName", where AvatarName is the first and last names of the avatar who created the functionality concatenated without a space, a period, and the name of the avatar's creation. This system should ensure that should two people come up with different ways to do the same thing, the COMPONENT names won't clash.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.AvatarScanner$LoginComplete
</nowiki></pre>

=== Connection Establishment ===
As described above, the LSL script initiates the communication by telling the viewer what channel it wants to talk on.

==== Connection Request ====
* The COMPONENT field's value is "DaleGlass.Viewer"
* The payload is "Connect$<channel>"

The fields are as follows:
* <channel> is the channel the script wants to talk on. For security, this SHOULD be randomly generated.

Example:
<pre><nowiki>
$VwrComm$0$DaleGlass.Viewer$Connect$12421
</nowiki></pre>

==== Viewer Reply ====
Viewer replies to the request by sending the message "OK" to the specified channel. Any other reply MUST be considered an error message.

After this, any further requests to the viewer from the object are replied to in on the specified channel.

=== Example ===
<pre><nowiki>
integer g_channel = 0; // Channel to talk on -- randomly generated
integer g_listen_handle = 0; // Listen handle

integer g_timeout = 30; // How long to wait for the viewer to reply

ViewerComm(string component, string data) {
llOwnerSay("$VwrComm$0$" + component + "$" + data);
}

default {
state_entry() {
// Generate a random channel number
g_channel = (integer)(llFRand(4294967295) - 2147483648);

// Set a timer in case the viewer doesn't reply
llSetTimerEvent(g_timeout);

// Listen for replies
g_listen_handle = llListen(g_channel, "", llGetOwner(), "");

// Send connection request
ViewerComm("DaleGlass.Viewer", "Connect$" + (string)channel);
}

timer() {
llListenRemove(g_listen_handle);
llOwnerSay("Client/Viewer connection timed out -- probably not supported");
}

listen( integer channel, string name, key id, string message ) {
if ( message == "OK" ) {
// Connection successful
llOwnerSay("Client/Viewer connection successful");
} else {
// Something went wrong
llOwnerSay("Client/Viewer connection error: " + message);
}
}
}
</nowiki></pre>

[[Category:Design Discussions]]

LSL To Client Communication

2007-06-23T00:38:56Z

Dale Glass: More details on viewer/script protocol

Build the Viewer on Linux

2007-06-21T01:44:19Z

Dale Glass: file dialogs don't work on 64 bit system

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

{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

= Building the client =
To build the Second Life Viewer you will first need to install the required tools and libraries.
The following sections online steps to build the client from source. To simplify building,
Linden labs has been nice enough to prepackage some of the libraries and bundled them up in an
additional tar file.

And while The Second Life Viewer is not a trivial build, and experience with building large
software packages will help you greatly - but don't be daunted, it should be simple once the
dependencies are in the right place.

The tasks are:
# Install required tools.
# Unpack source and art tree's from Linden Labs.
# Install libraries not shiped by Linden Labs.
# Unpack or install the other required libraries and headers.
# Compile.
 
 
== Required tools ==
There are a number of tools that need to be installed first.

* SCons build tool [package: scons]
* GCC 3.4 C/C++ compiler
** [debian/ubuntu: g++-3.4]
** [fedora: compat-gcc-34-c++]
** other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without a few simple code adjustments.
* yacc [suggest packages: bison]
* lex [suggest packages: flex]
 
 

== Unpack the source tree ==

You can get the source either from the source archives available at [[Source downloads]], or you can get it from [[Subversion]].

Using a source archive is the easier option, but if you plan to do active development and want to make your own modifications, while merging LL's changes, subversion will probably be much more convenient on the long term.

=== Getting the source from the source archives ===
Get the source from [[Source downloads]]. You will need all 3 archives: source, artwork and libraries.

Choose a location and unpack the source tree and the art work. They will be extracted into a
directory call linden.

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

=== Getting the source from Subversion ===
Select a source [[Source branches|branch]] to check out.

Check it out with:
<code>
% svn co http://svn.secondlife.com/svn/linden/<branch> [directory]
</code>
If you don't specify the directory, it'll use the name of the branch as the default.

Now you will have a directory with the source code. This only includes the source code itself, without the libraries or artwork. You will have to get them from the [[Source downloads]] and unpack them into the tree.

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:
<code>
% ln -sf <branch> linden
</code>

Now unpack the libraries and artwork:
<code>
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>

 

== Installing the required libraries (that Linden labs can not or does not provide)==
=== FMOD (audio) ===
* FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. 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
** Add FMOD=no to your Scons build command when compiling the source.
* If you want to use FMOD, fetch and unpack FMOD 3.75 <http://www.fmod.org/>
<code>
% wget http://www.fmod.org/files/fmodapi375linux.tar.gz
% tar -xzvf fmodapi375linux.tar.gz
% cd fmodapi375linux/
% cp api/inc/* ../linden/libraries/i686-linux/include/
% cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>
 
 

== Installing the required dependencies (prepackaged by Linden labs)==

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.
<code>
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>

If you choose to use the provide libs you can skip to
[[Compiling_the_viewer_%28Linux%29#Compiling|Compiling the client]].
 
=== Doing yourself ===
If you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries. You will have to install the following additional dependencies
listed below. Paths and package names given here are based on Ubuntu 6.06 and may vary
according to your Linux distribution.

==== List of libraries ====
* apr-1 [debian/ubuntu: libapr1.0-dev, fedora: apr-devel]

* aprutil-1 [debian/ubuntu: libaprutil1.0-dev, fedora: apr-util-devel]

* boost [debian/ubuntu: libboost-dev, fedora: boost-devel]

* boost-regex [debian/ubuntu: libboost-regex-dev]

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

* ELFIO <http://sourceforge.net/projects/elfio/>
** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so
<code>
% cd ELFIO && g++-3.4 -shared *.o -o libelfio.so
</code>

* expat [debian/ubuntu: libexpat1-dev, fedora: expat-devel]

* google-perftools library for the tcmalloc and stacktrace libraries. (memory checking)
**[fedora: google-perftools-devel.i386]
**[debian/ubuntu: libgoogle-perftools-dev

* GTK 2.x development headers
** [debian/ubuntu: libgtk2.0-dev
** [fedora: gtk2-devel]

* jpeglib
**[debian/ubuntu: libjpeg62-dev]
**[fedora: libjpeg-devel]

* OpenGL development headers: gl.h, glext.h, glu.h
**[debian/ubuntu: mesa-common-dev, libglu1-mesa-dev]
**[fedora: mesa-libGL-devel, mesa-libGLU-devel]

* OpenJPEG <http://www.openjpeg.org/>
** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
*** ''what does this mean?''
** 02-26-2007, another set of patches is required to Second Life to make it usable, that is fix a crash, make it look good, and speed it up. See https://jira.secondlife.com:443/browse/VWR-123
*** ''VWR-123 has been fixed: should this note be removed?''

* SDL [libsdl1.2-dev, fedora: SDL-devel]

* Vorbis [debian/ubuntu: libvorbis-dev, fedora: libvorbis-devel]

* X11 development headers: Xlib.h, and Xutil.h
**[debian/ubuntu: libx11-dev]
**[fedora: libX11-devel]

* xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
** Apply patches from the instructions in [[patch xmlrpc-epi]]
*** ''does this still work?''
** See also:
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-gcc4.1.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-use-system-expat.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-rename.patch
*** You have to regenerate autotools after applying the patches:
****libtoolize -c -f
****aclocal
****automake -c -a -f
****autoconf
*** The first patch fixes compiling on gcc 4. The second patch causes it to compile against the system expat, the version xmlrpc-epi comes with is broken and will not work. The last patch renames the library from xmlrpc to xmlrpc-epi, otherwise it conflicts with xmlrpc-c - which means the viewer then needs to be patched to link against xmlrpc-epi and not xmlrpc. These patches are from my Fedora package. On linux, I recommend these patches in favor of the Linden ones, as theirs seem to be for windows. (And mine actually work)
 
 

==== Copy headers and libraries into the source tree ====

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.

If you are using the easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:

* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.

<code>
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include

cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

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

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

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>
 
 

== Compiling ==
=== Build Types ===
The ''BUILD'' parameter specifies the build type. For normal usage, use '''release'''. If you plan to work on the source, choose '''releasenoopt''' or '''debug''', as these versions are unoptimized and much easier to debug.

* '''release''': Optimized build for release.
* '''releasenoopt''': Unoptimized build.
* '''debug''': Debug build with assertions.
* '''releasefordownload''': Optimized build for release, will create a .tar.gz with the files for distribution.
 
=== Building ===
=== Disable llMozLib ===
Add MOZLIB=no to your Scons build command when compiling the source.
 
<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.
 
 
== 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. 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:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
</code>

* 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=../../libraries/i686-linux/lib_release_client:${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 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

==== Automated libraries and headers adjustments, compilation and packaging ====

Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.30 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# The packaged build will be moved to your home directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro. Tested with SL v1.17 sources.

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

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
# Beware: libdb4 makes use of libapr... so you should keep USE_SYSTEM_APR
# and USE_SYSTEM_DB4 in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
USE_SYSTEM_FREETYPE2="yes"
USE_SYSTEM_PERFTOOLS="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp -mtune=athlon-xp"
TUNE_FLAGS=""

# Whether to build with the browser login screen or not:
WITH_MOZILLA="yes"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
if (($? == 0)) ; then
mv $PATH_TO_SOURCES/indra/newview/SecondLife*.tar.bz2 $HOME/
fi
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

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

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] && [ "$TEMP_BUILD_DIR" != "" ] && [ "$TEMP_BUILD_DIR" != "/" ] && [ "$TEMP_BUILD_DIR" != "." ] && [ "$TEMP_BUILD_DIR" != ".." ] && [ "$TEMP_BUILD_DIR" != "$HOME" ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

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

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

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

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
sed -e "s/# / /" $TEMP_BUILD_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
#mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

# Missing file... at least in v1.17.
touch $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-O2/-O2 $TUNE_FLAGS/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

compile
</nowiki>
</pre>
</code>
 
 

== FreeBSD ==

A list of patches is given for [[Compiling the viewer (FreeBSD)]].

User:Dale Glass

2007-06-19T20:20:51Z

Dale Glass: SVN source loading script

Evil Scripter and RL programmer.

Currently working on adding an avatar scanner to the SL client.

http://daleglass.net/images/screenshots/avlist6_001.jpg

Features:
* Shows a list of all avatars known to the client. This can be easily more than a standard 96m scanner, and seems to depend on rendering distance.

* Keeps an internal list of avatars, and continues showing avatars that disappeared in the list for several seconds to give people time to perform some action on them (intended to make it easier to deal with griefers that do something nasty, then teleport out)

* Shows Linden accounts in bold. This will be expanded later to highlight people who are very new, don't have a credit card on file, etc depending on user configuration.

* Allows easy access to IM, profiles, etc

* Allows to start a conference to multiple avatars around you, the same way it works in the friends list.

* Allows tracking an avatar by placing a beacon on it. In the case the selected avatar isn't a friend who gave map location permission, it works anyway by placing a beacon on the avatar's last known position. This of course only works so long the avatar being tracked is near enough to be seen by the user.

* Automatically retrieves the birth date, account type and payment data for all users shown. The data is of course cached, and if this is too much of an extra load, I'll implement a permanent on-disk cache. If data doesn't arrive, it will retry with an exponential backoff (starting from 1 minute, doubling until 30 minutes)

* Displays activity status: new, left the area, emitting particles, moving, playing sound

* Allows moving the camera to the avatar with a double click, as well as cycling the camera between all or only the marked avatars

* Partial TrustNet integration: retrieves scores, but can't rate yet

What is not done yet, but will be:

* Integration with my TrustNet system. See here for details:
http://daleglass.net/tikiwiki/tiki-index.php?page=TrustNetAvatarScanner
http://daleglass.net/tikiwiki/tiki-index.php?page=HowTrustNetWorks

* Integration with resident-run databases. For example, I've been asked whether I could make it automatically query a website with a database of buyers to be able to tell people who are using avatars made with copybot, for instance.

* Buttons for administrative actions such as ban/eject/freeze/etc

* Add activity status for typing and rezzing objects

* Also longer term, option to make the client stop rendering an avatar completely.

{{Jira Reporter}}

== Scripts ==

* http://daleglass.net/scripts/load_archive.pl -- Script for loading source archives into Subversion. See comments in the source for usage.

Source version control

2007-06-19T19:24:16Z

Dale Glass: distributed development, smerge sections

One of the problems in making large changes to the Second Life source is keeping track of changes, in order to be able to generate patches to submit. Also longer term, some way of keeping up with LL's changes to the source is needed. This page is an attempt to explain how to do that.

== Ad-hoc ==
If you're not familiar with any source control systems, you can try to not use any, and instead just use the diff and patch utilities. This approach is very strongly discouraged because it doesn't scale at all. Nevertheless, it works OK for smaller things, like 1 line fixes to the source.

First, create a copy of the source:
<code>
% cp -Rdp linden linden.orig
</code>

Do some work on the linden directory. To make a patch use 'diff -u':
<code>
% diff -ru linden.orig linden > my_modification.patch
</code>

Keep the patch around. If LL releases a new version you can apply it to the new source:
<code>
% cd linden
% patch -p0 < ../my_modification.patch
</code>

This method has many disadvantages: it wastes huge amounts of disk space, is inefficient and error prone.

== Subversion ==
Subversion is a much better option. However, it presents a bigger problem. LL offers a readonly [[Subversion]] repository that you can use to get the latest source. However, since you can't commit to it, you'll need to copy the source into your own repository. First, of all, you need to create your own repository. If you have several computers, you should do this on a machine you can reach from anywhere you might want to do development. Ideally it should be a machine accessible from the Internet.

For the purposes of the explanation, I will assume that your SVN repository is accessible through a web server at http://svn.example.com/secondlife. Check the Subversion manual for more information of how to access a repository.

=== Getting started ===
First, create a repository somewhere convenient. /var/lib is a common location for a server setup, but you can choose any other.
<code>
% svnadmin create /var/lib/svn/secondlife
</code>

Now create a local directory with the initial files. By convention, SVN repositories generally have "tags", "branches" and "trunk" directories at the top level. We won't create trunk yet. The main development happens in trunk. The 'vendor' directory is for holding the original SL source, with the latest version in vendor/current, and a tag in /vendor per SL release.
<code>
% mkdir tags
% mkdir branches
% mkdir vendor
% mkdir vendor/current
</code>

Import the basic structure into your SVN repository:
<code>
% svn import -m "Initial import" http://svn.example.com/secondlife
</code>

Now move the original directory out of the way, and check it out:
<code>
% svn co http://svn.example.com/secondlife
</code>

=== Importing the source ===
Now you have a working copy with the empty structure. Here comes the complicated part, how to integrate LL's source there and keep it up to date. Doing this is harder than it sounds, because you need to add new files, remove deleted ones, and keep track of renamed ones (if possible). The easiest way to do that is to use the svn-load-dirs utility.

First of all, get the SL source. Get the archive and extract it. I recommend checking in only the source package, and leaving the art and libraries out of the repository. The art is best left out because it's big and will slow things down if your SVN repository is located for instance on a shared hosting server. The libraries must be left out if you intend to let anybody else access your repository because some libraries in the archive can't be redistributed.

You should now have a "linden" directory with the source code. Now use svn-load-dirs to load it:

<code>
% svn-load-dirs -t 1.17.0.12 http://svn.example.com/vendor current linden
</code>

If your repository is accessed through the internet, this can take a while (even hours)

This will load the source from the linden directory, into http://svn.example.com/vendor/current, and at the same time create a tag in http://svn.example.com/vendor/1.17.0.12. The tag is a very good idea as it allows comparing LL releases easily, makes it easy to determine the last version you merged, and simplifies keeping up with LL releases a lot.

Now from your working copy, run "svn update":

<code>
% svn update
</code>

This will bring it up to date, and fetch the recently imported LL source. Now you can start your own branch:
<code>
% svn copy vendor/current trunk
</code>

Now you have the trunk branch for working in.

=== Merging LL releases ===
First, repeat the svn-load-dirs step above. Then you can merge the new changes into trunk:

<code>
% svn merge http://svn.example.com/vendor/<previously_merged_release> http://svn.example.com/vendor/current trunk
</code>

Now the new LL changes will be merged with your code. You can then "svn diff vendor/current trunk" to get a patch to submit.

== SVK ==

The above method is workable, but it's not ideal, because SVN uses a centralized model. To use Subversion ideally you'd need to have commit access on the LL server. While it's possible you might get it, not everybody will, and you almost certainly won't get it immediately. Since you can't use the server directly, svn-load-dirs is a required hack. It's definitely not ideal. svn-load-dirs loses the history from the original server, and can't properly track renames (it will ask you, and you'll have to figure out somehow).

=== Distributed Development ===
Unlike systems like SVN and CVS, SVK is made for distributed development. In a distributed system there's no central server. The "official" server if there is such a thing is only official because people choose to believe it is, not because there's anything special about it. Whatever external servers you mirror with SVK are only accessed when you tell to SVK to sync with the server. The rest of the time, no network connection is needed, even for using commands like "svk log" and "svk blame" which would require a connection with SVN. This is possible because SVK mirrors the whole repository locally.

SVK makes it very convenient to keep in sync with external SVN servers. With just one command it'll fetch all the new revisions from a SVN server. Then you can do the actual merging and conflict resolution offline. Once you're done merging, you can push the changes to your own server. Another user could then use your server as a base for their code, and so on.

=== Smart Merge ===
The "smerge" or "sm" command is used very often when working with SVK. It's similar to the "svn merge" command in that it merges changes from one branch to another. However, "smerge" is much smarter than SVN's version. While the "svn merge" needs to be given a revision range or two branches so that it can compute what to merge, "svk smerge" automatically figures out, by finding the common ancestor of the branch you're merging from, and the branch you're merging to.

For example, suppose this scenario: We have the original source in /vendor/current, a branch /branches/foo, and trunk /trunk. Both /branches/foo and /trunk were created from /vendor/current at some point.

With SVN, we can merge the changes introduced in the "foo" branch into trunk like this:
<code>
% svn merge http://svn.example.com/vendor/current http://svn.example.com/branches/foo trunk
</code>

Now suppose that after the merge is done, somebody commits a new change to /branches/foo. With SVN we've now lost the ability to do an easy merge. Repeating the above command again would try to merge changes that were already merged, plus the newly committed changes. To correctly merge only the newly committed code, we must figure out what was the last revision we merged, and start from there.

SVK is much more clever in this respect. Here's how you'd do that:
<code>
% svk merge //project/branches/foo //project/trunk
</code>

Notice how we don't specify the vendor branch here. This is because SVK already knows what is the ancestor of both branches, and automatically figures out what to merge into trunk. Once you run this command, it'll record that as the last merge point. Repeating the command immediately would succeed without doing anything, because there aren't any new changes to merge. If something new is committed into //project/branches/foo, then only that would be merged.

This makes working with branches much easier in SVK. While with SVN you'd need to keep track of what you merged where, SVK does it for you.

=== Getting started ===
First of all, you need to mirror the SVN repository. This takes quite some time, but only needs to be done once. Run this command:

<code>
% svk mirror http://svn.secondlife.com/svn/linden //mirror/secondlife
% svk sync //mirror/secondlife
</code>

This will make SVK read the whole LL repository, with all its branches and revisions and store them on your hard disk (in your home directory).

When you're done, do the same to a repository you can write to (since you can't write to the LL one):
<code>
% svk mirror http://svn.example.com/sl //mirror/myproject
% svk sync //mirror/myproject
</code>

//mirror/secondlife and //mirror/myproject are special paths used by SVK. They're links to the actual repositories. Doing something to //mirror/myproject would result in changes being sent to your SVN server.

=== Creating the first branch ===
First, copy the branch you want to work with to your own server:

<code>
% svk mkdir //mirror/myproject/branches
% svk mkdir //mirror/myproject/branches/buildfixes
% svk smerge -B //mirror/secondlife/release //mirror/myproject/branches/buildfixes
</code>

"smerge" stands for "smart merge" and is a very cool thing. It intelligently merges starting from the part where you left. Since there's no common ancestor to both //mirror/secondlife/release and //mirror/myproject/branches/buildfixes (there can't be, since buildfixes is empty), you need to tell it to merge everything with the -B argument. After this initial step, further merges can be performed automatically.

Here we're creating a "buildfixes" branch on our own server, starting from the LL release source. I use the "buildfixes" branch as a starting point for all the others. It contains only the changes needed to get the source to build.

=== Creating local branches ===
A very good thing about SVK is that you can do useful work without a network connection. First, we'll create copies of the repositories for local use:
<code>
% svk copy //mirror/secondlife //ll/
% svk copy //mirror/myproject //myproject/
</code>

Changes made to these aren't automatically propagated to the SVN servers. They're remembered until you want to push them to the server. This means that you can sit on a plane without any sort of network connection, and still use the usual SVN commands -- check the log, commit, revert changes, etc.

=== Creating a new development branch ===
Now that the buildfixes branch is created, we can create another starting from it:

<code>
% svk mkdir //myproject/trunk
% svk smerge -B //myproject/branches/buildfixes //myproject/trunk
</code>

Notice how this time there won't be any network access. To push the changes to your server, do:

<code>
% svk smerge //myproject //mirror/myproject
</code>

Now suppose you updated the buildfixes branch, and want to propagate the changes. It's simple:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

svk smerge keeps track of what was the last merge, and it automatically merges changes that weren't merged yet. Unlike with SVN, you don't need to keep track of revision numbers of make tags, it automatically does the right thing for you.

=== Merging new LL code ===
Now suppose LL releases a new revision and you want to merge it with your changes. This is easy:

<code>
% svk sync //mirror/secondlife
% svk smerge //mirror/secondlife //ll
% svk smerge //mirror/secondlife //myproject/branches/buildfixes
</code>

Since the buildfixes branch changed, you can propagate the changes further to the trunk branch:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

And push it to your SVN server:
<code>
% svk smerge //myproject //mirror/myproject
</code>

Source version control

2007-06-19T10:12:41Z

Dale Glass: sections

One of the problems in making large changes to the Second Life source is keeping track of changes, in order to be able to generate patches to submit. Also longer term, some way of keeping up with LL's changes to the source is needed. This page is an attempt to explain how to do that.

== Ad-hoc ==
If you're not familiar with any source control systems, you can try to not use any, and instead just use the diff and patch utilities. This approach is very strongly discouraged because it doesn't scale at all. Nevertheless, it works OK for smaller things, like 1 line fixes to the source.

First, create a copy of the source:
<code>
% cp -Rdp linden linden.orig
</code>

Do some work on the linden directory. To make a patch use 'diff -u':
<code>
% diff -ru linden.orig linden > my_modification.patch
</code>

Keep the patch around. If LL releases a new version you can apply it to the new source:
<code>
% cd linden
% patch -p0 < ../my_modification.patch
</code>

This method has many disadvantages: it wastes huge amounts of disk space, is inefficient and error prone.

== Subversion ==
Subversion is a much better option. However, it presents a bigger problem. LL offers a readonly [[Subversion]] repository that you can use to get the latest source. However, since you can't commit to it, you'll need to copy the source into your own repository. First, of all, you need to create your own repository. If you have several computers, you should do this on a machine you can reach from anywhere you might want to do development. Ideally it should be a machine accessible from the Internet.

For the purposes of the explanation, I will assume that your SVN repository is accessible through a web server at http://svn.example.com/secondlife. Check the Subversion manual for more information of how to access a repository.

=== Getting started ===
First, create a repository somewhere convenient. /var/lib is a common location for a server setup, but you can choose any other.
<code>
% svnadmin create /var/lib/svn/secondlife
</code>

Now create a local directory with the initial files. By convention, SVN repositories generally have "tags", "branches" and "trunk" directories at the top level. We won't create trunk yet. The main development happens in trunk. The 'vendor' directory is for holding the original SL source, with the latest version in vendor/current, and a tag in /vendor per SL release.
<code>
% mkdir tags
% mkdir branches
% mkdir vendor
% mkdir vendor/current
</code>

Import the basic structure into your SVN repository:
<code>
% svn import -m "Initial import" http://svn.example.com/secondlife
</code>

Now move the original directory out of the way, and check it out:
<code>
% svn co http://svn.example.com/secondlife
</code>

=== Importing the source ===
Now you have a working copy with the empty structure. Here comes the complicated part, how to integrate LL's source there and keep it up to date. Doing this is harder than it sounds, because you need to add new files, remove deleted ones, and keep track of renamed ones (if possible). The easiest way to do that is to use the svn-load-dirs utility.

First of all, get the SL source. Get the archive and extract it. I recommend checking in only the source package, and leaving the art and libraries out of the repository. The art is best left out because it's big and will slow things down if your SVN repository is located for instance on a shared hosting server. The libraries must be left out if you intend to let anybody else access your repository because some libraries in the archive can't be redistributed.

You should now have a "linden" directory with the source code. Now use svn-load-dirs to load it:

<code>
% svn-load-dirs -t 1.17.0.12 http://svn.example.com/vendor current linden
</code>

If your repository is accessed through the internet, this can take a while (even hours)

This will load the source from the linden directory, into http://svn.example.com/vendor/current, and at the same time create a tag in http://svn.example.com/vendor/1.17.0.12. The tag is a very good idea as it allows comparing LL releases easily, makes it easy to determine the last version you merged, and simplifies keeping up with LL releases a lot.

Now from your working copy, run "svn update":

<code>
% svn update
</code>

This will bring it up to date, and fetch the recently imported LL source. Now you can start your own branch:
<code>
% svn copy vendor/current trunk
</code>

Now you have the trunk branch for working in.

=== Merging LL releases ===
First, repeat the svn-load-dirs step above. Then you can merge the new changes into trunk:

<code>
% svn merge http://svn.example.com/vendor/<previously_merged_release> http://svn.example.com/vendor/current trunk
</code>

Now the new LL changes will be merged with your code. You can then "svn diff vendor/current trunk" to get a patch to submit.

== SVK ==

The above method is workable, but it's not ideal, because SVN uses a centralized model. To use Subversion ideally you'd need to have commit access on the LL server. While it's possible you might get it, not everybody will, and you almost certainly won't get it immediately. Since you can't use the server directly, svn-load-dirs is a required hack. It's definitely not ideal. svn-load-dirs loses the history from the original server, and can't properly track renames (it will ask you, and you'll have to figure out somehow).

An alternative is SVK. SVK is a distributed source control system based on SVN. In a distributed system there's no central server. The "official" server if there is such a thing is only official because people choose to believe it is, not because there's anything special about it.

A crucial difference is that SVK can mirror the LL SVN repository, keeping all the data about revisions, with one command. Then you can make your changes to that, and push them to your own SVN server. If you make that available, somebody could mirror that, and so on. SVK makes it very convenient for people to create their own branches based on bits from here and there.

=== Getting started ===
First of all, you need to mirror the SVN repository. This takes quite some time, but only needs to be done once. Run this command:

<code>
% svk mirror http://svn.secondlife.com/svn/linden //mirror/secondlife
% svk sync //mirror/secondlife
</code>

This will make SVK read the whole LL repository, with all its branches and revisions and store them on your hard disk (in your home directory).

When you're done, do the same to a repository you can write to (since you can't write to the LL one):
<code>
% svk mirror http://svn.example.com/sl //mirror/myproject
% svk sync //mirror/myproject
</code>

//mirror/secondlife and //mirror/myproject are special paths used by SVK. They're links to the actual repositories. Doing something to //mirror/myproject would result in changes being sent to your SVN server.

=== Creating the first branch ===
First, copy the branch you want to work with to your own server:

<code>
% svk mkdir //mirror/myproject/branches
% svk mkdir //mirror/myproject/branches/buildfixes
% svk smerge -B //mirror/secondlife/release //mirror/myproject/branches/buildfixes
</code>

"smerge" stands for "smart merge" and is a very cool thing. It intelligently merges starting from the part where you left. Since there's no common ancestor to both //mirror/secondlife/release and //mirror/myproject/branches/buildfixes (there can't be, since buildfixes is empty), you need to tell it to merge everything with the -B argument. After this initial step, further merges can be performed automatically.

Here we're creating a "buildfixes" branch on our own server, starting from the LL release source. I use the "buildfixes" branch as a starting point for all the others. It contains only the changes needed to get the source to build.

=== Creating local branches ===
A very good thing about SVK is that you can do useful work without a network connection. First, we'll create copies of the repositories for local use:
<code>
% svk copy //mirror/secondlife //ll/
% svk copy //mirror/myproject //myproject/
</code>

Changes made to these aren't automatically propagated to the SVN servers. They're remembered until you want to push them to the server. This means that you can sit on a plane without any sort of network connection, and still use the usual SVN commands -- check the log, commit, revert changes, etc.

=== Creating a new development branch ===
Now that the buildfixes branch is created, we can create another starting from it:

<code>
% svk mkdir //myproject/trunk
% svk smerge -B //myproject/branches/buildfixes //myproject/trunk
</code>

Notice how this time there won't be any network access. To push the changes to your server, do:

<code>
% svk smerge //myproject //mirror/myproject
</code>

Now suppose you updated the buildfixes branch, and want to propagate the changes. It's simple:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

svk smerge keeps track of what was the last merge, and it automatically merges changes that weren't merged yet. Unlike with SVN, you don't need to keep track of revision numbers of make tags, it automatically does the right thing for you.

=== Merging new LL code ===
Now suppose LL releases a new revision and you want to merge it with your changes. This is easy:

<code>
% svk sync //mirror/secondlife
% svk smerge //mirror/secondlife //ll
% svk smerge //mirror/secondlife //myproject/branches/buildfixes
</code>

Since the buildfixes branch changed, you can propagate the changes further to the trunk branch:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

And push it to your SVN server:
<code>
% svk smerge //myproject //mirror/myproject
</code>

Source version control

2007-06-19T10:10:13Z

Dale Glass: typo fix, explain smerge -B argument

One of the problems in making large changes to the Second Life source is keeping track of changes, in order to be able to generate patches to submit. Also longer term, some way of keeping up with LL's changes to the source is needed. This page is an attempt to explain how to do that.

== Ad-hoc ==
If you're not familiar with any source control systems, you can try to not use any, and instead just use the diff and patch utilities. This approach is very strongly discouraged because it doesn't scale at all. Nevertheless, it works OK for smaller things, like 1 line fixes to the source.

First, create a copy of the source:
<code>
% cp -Rdp linden linden.orig
</code>

Do some work on the linden directory. To make a patch use 'diff -u':
<code>
% diff -ru linden.orig linden > my_modification.patch
</code>

Keep the patch around. If LL releases a new version you can apply it to the new source:
<code>
% cd linden
% patch -p0 < ../my_modification.patch
</code>

This method has many disadvantages: it wastes huge amounts of disk space, is inefficient and error prone.

== Subversion ==
Subversion is a much better option. However, it presents a bigger problem. LL offers a readonly [[Subversion]] repository that you can use to get the latest source. However, since you can't commit to it, you'll need to copy the source into your own repository. First, of all, you need to create your own repository. If you have several computers, you should do this on a machine you can reach from anywhere you might want to do development. Ideally it should be a machine accessible from the Internet.

For the purposes of the explanation, I will assume that your SVN repository is accessible through a web server at http://svn.example.com/secondlife. Check the Subversion manual for more information of how to access a repository.

First, create a repository somewhere convenient. /var/lib is a common location for a server setup, but you can choose any other.
<code>
% svnadmin create /var/lib/svn/secondlife
</code>

Now create a local directory with the initial files. By convention, SVN repositories generally have "tags", "branches" and "trunk" directories at the top level. We won't create trunk yet. The main development happens in trunk. The 'vendor' directory is for holding the original SL source, with the latest version in vendor/current, and a tag in /vendor per SL release.
<code>
% mkdir tags
% mkdir branches
% mkdir vendor
% mkdir vendor/current
</code>

Import the basic structure into your SVN repository:
<code>
% svn import -m "Initial import" http://svn.example.com/secondlife
</code>

Now move the original directory out of the way, and check it out:
<code>
% svn co http://svn.example.com/secondlife
</code>

Now you have a working copy with the empty structure. Here comes the complicated part, how to integrate LL's source there and keep it up to date. Doing this is harder than it sounds, because you need to add new files, remove deleted ones, and keep track of renamed ones (if possible). The easiest way to do that is to use the svn-load-dirs utility.

First of all, get the SL source. Get the archive and extract it. I recommend checking in only the source package, and leaving the art and libraries out of the repository. The art is best left out because it's big and will slow things down if your SVN repository is located for instance on a shared hosting server. The libraries must be left out if you intend to let anybody else access your repository because some libraries in the archive can't be redistributed.

You should now have a "linden" directory with the source code. Now use svn-load-dirs to load it:

<code>
% svn-load-dirs -t 1.17.0.12 http://svn.example.com/vendor current linden
</code>

If your repository is accessed through the internet, this can take a while (even hours)

This will load the source from the linden directory, into http://svn.example.com/vendor/current, and at the same time create a tag in http://svn.example.com/vendor/1.17.0.12. The tag is a very good idea as it allows comparing LL releases easily, makes it easy to determine the last version you merged, and simplifies keeping up with LL releases a lot.

Now from your working copy, run "svn update":

<code>
% svn update
</code>

This will bring it up to date, and fetch the recently imported LL source. Now you can start your own branch:
<code>
% svn copy vendor/current trunk
</code>

Now you have the trunk branch for working in. Go and do something in there. Now suppose LL releases a new version. First, repeat the svn-load-dirs step above. Then you can merge the new changes into trunk:

<code>
% svn merge http://svn.example.com/vendor/<previously_merged_release> http://svn.example.com/vendor/current trunk
</code>

Now the new LL changes will be merged with your code. You can then "svn diff vendor/current trunk" to get a patch to submit.

== SVK ==

The above method is workable, but it's not ideal, because SVN uses a centralized model. To use Subversion ideally you'd need to have commit access on the LL server. While it's possible you might get it, not everybody will, and you almost certainly won't get it immediately. Since you can't use the server directly, svn-load-dirs is a required hack. It's definitely not ideal. svn-load-dirs loses the history from the original server, and can't properly track renames (it will ask you, and you'll have to figure out somehow).

An alternative is SVK. SVK is a distributed source control system based on SVN. In a distributed system there's no central server. The "official" server if there is such a thing is only official because people choose to believe it is, not because there's anything special about it.

A crucial difference is that SVK can mirror the LL SVN repository, keeping all the data about revisions, with one command. Then you can make your changes to that, and push them to your own SVN server. If you make that available, somebody could mirror that, and so on. SVK makes it very convenient for people to create their own branches based on bits from here and there.

=== Getting started ===
First of all, you need to mirror the SVN repository. This takes quite some time, but only needs to be done once. Run this command:

<code>
% svk mirror http://svn.secondlife.com/svn/linden //mirror/secondlife
% svk sync //mirror/secondlife
</code>

This will make SVK read the whole LL repository, with all its branches and revisions and store them on your hard disk (in your home directory).

When you're done, do the same to a repository you can write to (since you can't write to the LL one):
<code>
% svk mirror http://svn.example.com/sl //mirror/myproject
% svk sync //mirror/myproject
</code>

//mirror/secondlife and //mirror/myproject are special paths used by SVK. They're links to the actual repositories. Doing something to //mirror/myproject would result in changes being sent to your SVN server.

=== Creating the first branch ===
First, copy the branch you want to work with to your own server:

<code>
% svk mkdir //mirror/myproject/branches
% svk mkdir //mirror/myproject/branches/buildfixes
% svk smerge -B //mirror/secondlife/release //mirror/myproject/branches/buildfixes
</code>

"smerge" stands for "smart merge" and is a very cool thing. It intelligently merges starting from the part where you left. Since there's no common ancestor to both //mirror/secondlife/release and //mirror/myproject/branches/buildfixes (there can't be, since buildfixes is empty), you need to tell it to merge everything with the -B argument. After this initial step, further merges can be performed automatically.

Here we're creating a "buildfixes" branch on our own server, starting from the LL release source. I use the "buildfixes" branch as a starting point for all the others. It contains only the changes needed to get the source to build.

=== Creating local branches ===
A very good thing about SVK is that you can do useful work without a network connection. First, we'll create copies of the repositories for local use:
<code>
% svk copy //mirror/secondlife //ll/
% svk copy //mirror/myproject //myproject/
</code>

Changes made to these aren't automatically propagated to the SVN servers. They're remembered until you want to push them to the server. This means that you can sit on a plane without any sort of network connection, and still use the usual SVN commands -- check the log, commit, revert changes, etc.

=== Creating a new development branch ===
Now that the buildfixes branch is created, we can create another starting from it:

<code>
% svk mkdir //myproject/trunk
% svk smerge -B //myproject/branches/buildfixes //myproject/trunk
</code>

Notice how this time there won't be any network access. To push the changes to your server, do:

<code>
% svk smerge //myproject //mirror/myproject
</code>

Now suppose you updated the buildfixes branch, and want to propagate the changes. It's simple:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

svk smerge keeps track of what was the last merge, and it automatically merges changes that weren't merged yet. Unlike with SVN, you don't need to keep track of revision numbers of make tags, it automatically does the right thing for you.

=== Merging new LL code ===
Now suppose LL releases a new revision and you want to merge it with your changes. This is easy:

<code>
% svk sync //mirror/secondlife
% svk smerge //mirror/secondlife //ll
% svk smerge //mirror/secondlife //myproject/branches/buildfixes
</code>

Since the buildfixes branch changed, you can propagate the changes further to the trunk branch:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

And push it to your SVN server:
<code>
% svk smerge //myproject //mirror/myproject
</code>

Source version control

2007-06-19T08:53:55Z

Dale Glass: fixed trunk path

One of the problems in making large changes to the Second Life source is keeping track of changes, in order to be able to generate patches to submit. Also longer term, some way of keeping up with LL's changes to the source is needed. This page is an attempt to explain how to do that.

== Ad-hoc ==
If you're not familiar with any source control systems, you can try to not use any, and instead just use the diff and patch utilities. This approach is very strongly discouraged because it doesn't scale at all. Nevertheless, it works OK for smaller things, like 1 line fixes to the source.

First, create a copy of the source:
<code>
% cp -Rdp linden linden.orig
</code>

Do some work on the linden directory. To make a patch use 'diff -u':
<code>
% diff -ru linden.orig linden > my_modification.patch
</code>

Keep the patch around. If LL releases a new version you can apply it to the new source:
<code>
% cd linden
% patch -p0 < ../my_modification.patch
</code>

This method has many disadvantages: it wastes huge amounts of disk space, is inefficient and error prone.

== Subversion ==
Subversion is a much better option. However, it presents a bigger problem. LL offers a readonly [[Subversion]] repository that you can use to get the latest source. However, since you can't commit to it, you'll need to copy the source into your own repository. First, of all, you need to create your own repository. If you have several computers, you should do this on a machine you can reach from anywhere you might want to do development. Ideally it should be a machine accessible from the Internet.

For the purposes of the explanation, I will assume that your SVN repository is accessible through a web server at http://svn.example.com/secondlife. Check the Subversion manual for more information of how to access a repository.

First, create a repository somewhere convenient. /var/lib is a common location for a server setup, but you can choose any other.
<code>
% svnadmin create /var/lib/svn/secondlife
</code>

Now create a local directory with the initial files. By convention, SVN repositories generally have "tags", "branches" and "trunk" directories at the top level. We won't create trunk yet. The main development happens in trunk. The 'vendor' directory is for holding the original SL source, with the latest version in vendor/current, and a tag in /vendor per SL release.
<code>
% mkdir tags
% mkdir branches
% mkdir vendor
% mkdir vendor/current
</code>

Import the basic structure into your SVN repository:
<code>
% svn import -m "Initial import" http://svn.example.com/secondlife
</code>

Now move the original directory out of the way, and check it out:
<code>
% svn co http://svn.example.com/secondlife
</code>

Now you have a working copy with the empty structure. Here comes the complicated part, how to integrate LL's source there and keep it up to date. Doing this is harder than it sounds, because you need to add new files, remove deleted ones, and keep track of renamed ones (if possible). The easiest way to do that is to use the svn-load-dirs utility.

First of all, get the SL source. Get the archive and extract it. I recommend checking in only the source package, and leaving the art and libraries out of the repository. The art is best left out because it's big and will slow things down if your SVN repository is located for instance on a shared hosting server. The libraries must be left out if you intend to let anybody else access your repository because some libraries in the archive can't be redistributed.

You should now have a "linden" directory with the source code. Now use svn-load-dirs to load it:

<code>
% svn-load-dirs -t 1.17.0.12 http://svn.example.com/vendor current linden
</code>

If your repository is accessed through the internet, this can take a while (even hours)

This will load the source from the linden directory, into http://svn.example.com/vendor/current, and at the same time create a tag in http://svn.example.com/vendor/1.17.0.12. The tag is a very good idea as it allows comparing LL releases easily, makes it easy to determine the last version you merged, and simplifies keeping up with LL releases a lot.

Now from your working copy, run "svn update":

<code>
% svn update
</code>

This will bring it up to date, and fetch the recently imported LL source. Now you can start your own branch:
<code>
% svn copy vendor/current trunk
</code>

Now you have the trunk branch for working in. Go and do something in there. Now suppose LL releases a new version. First, repeat the svn-load-dirs step above. Then you can merge the new changes into trunk:

<code>
% svn merge http://svn.example.com/vendor/<previously_merged_release> http://svn.example.com/vendor/current trunk
</code>

Now the new LL changes will be merged with your code. You can then "svn diff vendor/current trunk" to get a patch to submit.

== SVK ==

The above method is workable, but it's not ideal, because SVN uses a centralized model. To use Subversion ideally you'd need to have commit access on the LL server. While it's possible you might get it, not everybody will, and you almost certainly won't get it immediately. Since you can't use the server directly, svn-load-dirs is a required hack. It's definitely not ideal. svn-load-dirs loses the history from the original server, and can't properly track renames (it will ask you, and you'll have to figure out somehow).

An alternative is SVK. SVK is a distributed source control system based on SVN. In a distributed system there's no central server. The "official" server if there is such a thing is only official because people choose to believe it is, not because there's anything special about it.

A crucial difference is that SVK can mirror the LL SVN repository, keeping all the data about revisions, with one command. Then you can make your changes to that, and push them to your own SVN server. If you make that available, somebody could mirror that, and so on. SVK makes it very convenient for people to create their own branches based on bits from here and there.

=== Getting started ===
First of all, you need to mirror the SVN repository. This takes quite some time, but only needs to be done once. Run this command:

<code>
% svk mirror http://svn.secondlife.com/svn/linden //mirror/secondlife
% svk sync //mirror/secondlife
</code>

This will make SVK read the whole LL repository, with all its branches and revisions and store them on your hard disk (in your home directory).

When you're done, do the same to a repository you can write to (since you can't write to the LL one):
<code>
% svk mirror http://svn.example.com/sl //mirror/myproject
% svk sync //mirror/myproject
</code>

//mirror/secondlife and //mirror/myproject are special paths used by SVK. They're links to the actual repositories. Doing something to //mirror/myproject would result in changes being sent to your SVN server.

=== Creating the first branch ===
First, copy the branch you want to work with to your own server:

<code>
% svk mkdir //mirror/myproject/branches
% svk mkdir //mirror/myproject/branches/buildfixes
% svk smerge -B //mirror/secondlife/relese //mirror/myproject/branches/buildfixes
</code>

"smerge" stands for "smart merge" and is a very cool thing. It intelligently merges starting from the part where you left. This will be explained in more detail below.

Here we're creating a "buildfixes" branch on our own server, starting from the LL release source. I use the "buildfixes" branch as a starting point for all the others. It contains only the changes needed to get the source to build.

=== Creating local branches ===
A very good thing about SVK is that you can do useful work without a network connection. First, we'll create copies of the repositories for local use:
<code>
% svk copy //mirror/secondlife //ll/
% svk copy //mirror/myproject //myproject/
</code>

Changes made to these aren't automatically propagated to the SVN servers. They're remembered until you want to push them to the server. This means that you can sit on a plane without any sort of network connection, and still use the usual SVN commands -- check the log, commit, revert changes, etc.

=== Creating a new development branch ===
Now that the buildfixes branch is created, we can create another starting from it:

<code>
% svk mkdir //myproject/trunk
% svk smerge -B //myproject/branches/buildfixes //myproject/trunk
</code>

Notice how this time there won't be any network access. To push the changes to your server, do:

<code>
% svk smerge //myproject //mirror/myproject
</code>

Now suppose you updated the buildfixes branch, and want to propagate the changes. It's simple:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

svk smerge keeps track of what was the last merge, and it automatically merges changes that weren't merged yet. Unlike with SVN, you don't need to keep track of revision numbers of make tags, it automatically does the right thing for you.

=== Merging new LL code ===
Now suppose LL releases a new revision and you want to merge it with your changes. This is easy:

<code>
% svk sync //mirror/secondlife
% svk smerge //mirror/secondlife //ll
% svk smerge //mirror/secondlife //myproject/branches/buildfixes
</code>

Since the buildfixes branch changed, you can propagate the changes further to the trunk branch:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

And push it to your SVN server:
<code>
% svk smerge //myproject //mirror/myproject
</code>

Source version control

2007-06-19T02:17:13Z

Dale Glass: Intial draft of SVK section

One of the problems in making large changes to the Second Life source is keeping track of changes, in order to be able to generate patches to submit. Also longer term, some way of keeping up with LL's changes to the source is needed. This page is an attempt to explain how to do that.

== Ad-hoc ==
If you're not familiar with any source control systems, you can try to not use any, and instead just use the diff and patch utilities. This approach is very strongly discouraged because it doesn't scale at all. Nevertheless, it works OK for smaller things, like 1 line fixes to the source.

First, create a copy of the source:
<code>
% cp -Rdp linden linden.orig
</code>

Do some work on the linden directory. To make a patch use 'diff -u':
<code>
% diff -ru linden.orig linden > my_modification.patch
</code>

Keep the patch around. If LL releases a new version you can apply it to the new source:
<code>
% cd linden
% patch -p0 < ../my_modification.patch
</code>

This method has many disadvantages: it wastes huge amounts of disk space, is inefficient and error prone.

== Subversion ==
Subversion is a much better option. However, it presents a bigger problem. LL offers a readonly [[Subversion]] repository that you can use to get the latest source. However, since you can't commit to it, you'll need to copy the source into your own repository. First, of all, you need to create your own repository. If you have several computers, you should do this on a machine you can reach from anywhere you might want to do development. Ideally it should be a machine accessible from the Internet.

For the purposes of the explanation, I will assume that your SVN repository is accessible through a web server at http://svn.example.com/secondlife. Check the Subversion manual for more information of how to access a repository.

First, create a repository somewhere convenient. /var/lib is a common location for a server setup, but you can choose any other.
<code>
% svnadmin create /var/lib/svn/secondlife
</code>

Now create a local directory with the initial files. By convention, SVN repositories generally have "tags", "branches" and "trunk" directories at the top level. We won't create trunk yet. The main development happens in trunk. The 'vendor' directory is for holding the original SL source, with the latest version in vendor/current, and a tag in /vendor per SL release.
<code>
% mkdir tags
% mkdir branches
% mkdir vendor
% mkdir vendor/current
</code>

Import the basic structure into your SVN repository:
<code>
% svn import -m "Initial import" http://svn.example.com/secondlife
</code>

Now move the original directory out of the way, and check it out:
<code>
% svn co http://svn.example.com/secondlife
</code>

Now you have a working copy with the empty structure. Here comes the complicated part, how to integrate LL's source there and keep it up to date. Doing this is harder than it sounds, because you need to add new files, remove deleted ones, and keep track of renamed ones (if possible). The easiest way to do that is to use the svn-load-dirs utility.

First of all, get the SL source. Get the archive and extract it. I recommend checking in only the source package, and leaving the art and libraries out of the repository. The art is best left out because it's big and will slow things down if your SVN repository is located for instance on a shared hosting server. The libraries must be left out if you intend to let anybody else access your repository because some libraries in the archive can't be redistributed.

You should now have a "linden" directory with the source code. Now use svn-load-dirs to load it:

<code>
% svn-load-dirs -t 1.17.0.12 http://svn.example.com/vendor current linden
</code>

If your repository is accessed through the internet, this can take a while (even hours)

This will load the source from the linden directory, into http://svn.example.com/vendor/current, and at the same time create a tag in http://svn.example.com/vendor/1.17.0.12. The tag is a very good idea as it allows comparing LL releases easily, makes it easy to determine the last version you merged, and simplifies keeping up with LL releases a lot.

Now from your working copy, run "svn update":

<code>
% svn update
</code>

This will bring it up to date, and fetch the recently imported LL source. Now you can start your own branch:
<code>
% svn copy vendor/current trunk
</code>

Now you have the trunk branch for working in. Go and do something in there. Now suppose LL releases a new version. First, repeat the svn-load-dirs step above. Then you can merge the new changes into trunk:

<code>
% svn merge http://svn.example.com/vendor/<previously_merged_release> http://svn.example.com/vendor/current trunk
</code>

Now the new LL changes will be merged with your code. You can then "svn diff vendor/current trunk" to get a patch to submit.

== SVK ==

The above method is workable, but it's not ideal, because SVN uses a centralized model. To use Subversion ideally you'd need to have commit access on the LL server. While it's possible you might get it, not everybody will, and you almost certainly won't get it immediately. Since you can't use the server directly, svn-load-dirs is required hack. It's definitely not ideal. svn-load-dirs loses the history from the original server, and can't properly track renames (it will ask you, and you'll have to figure out somehow).

An alternative is SVK. SVK is a distributed source control system based on SVN. In a distributed system there's no central server. The "official" server if there is such a thing is only official because people choose to believe it is, not because there's anything special about it.

A crucial difference is that SVK can mirror the LL SVN repository, keeping all the data about revisions, with one command. Then you can make your changes to that, and push them to your own SVN server. If you make that available, somebody could mirror that, and so on. SVK makes it very convenient for people to create their own branches based on bits from here and there.

=== Getting started ===
First of all, you need to mirror the SVN repository. This takes quite some time, but only needs to be done once. Run this command:

<code>
% svk mirror http://svn.secondlife.com/svn/linden //mirror/secondlife
% svk sync //mirror/secondlife
</code>

This will make SVK read the whole LL repository, with all its branches and revisions and store them on your hard disk (in your home directory).

When you're done, do the same to a repository you can write to (since you can't write to the LL one):
<code>
% svk mirror http://svn.example.com/sl //mirror/myproject
% svk sync //mirror/myproject
</code>

//mirror/secondlife and //mirror/myproject are special paths used by SVK. They're links to the actual repositories. Doing something to //mirror/myproject would result in changes being sent to your SVN server.

=== Creating the first branch ===
First, copy the branch you want to work with to your own server:

<code>
% svk mkdir //mirror/myproject/branches
% svk mkdir //mirror/myproject/branches/buildfixes
% svk smerge -B //mirror/secondlife/relese //mirror/myproject/branches/buildfixes
</code>

"smerge" stands for "smart merge" and is a very cool thing. It intelligently merges starting from the part where you left. This will be explained in more detail below.

Here we're creating a "buildfixes" branch on our own server, starting from the LL release source. I use the "buildfixes" branch as a starting point for all the others. It contains only the changes needed to get the source to build.

=== Creating local branches ===
A very good thing about SVK is that you can do useful work without a network connection. First, we'll create copies of the repositories for local use:
<code>
% svk copy //mirror/secondlife //ll/
% svk copy //mirror/myproject //myproject/
</code>

Changes made to these aren't automatically propagated to the SVN servers. They're remembered until you want to push them to the server. This means that you can sit on a plane without any sort of network connection, and still use the usual SVN commands -- check the log, commit, revert changes, etc.

=== Creating a new development branch ===
Now that the buildfixes branch is created, we can create another starting from it:

<code>
% svk mkdir //myproject/trunk
% svk smerge -B //myproject/branches/buildfixes //myproject/trunk
</code>

Notice how this time there won't be any network access. To push the changes to your server, do:

<code>
% svk smerge //myproject //mirror/myproject
</code>

Now suppose you updated the buildfixes branch, and want to propagate the changes. It's simple:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/branches/trunk
</code>

svk smerge keeps track of what was the last merge, and it automatically merges changes that weren't merged yet. Unlike with SVN, you don't need to keep track of revision numbers of make tags, it automatically does the right thing for you.

=== Merging new LL code ===
Now suppose LL releases a new revision and you want to merge it with your changes. This is easy:

<code>
% svk sync //mirror/secondlife
% svk smerge //mirror/secondlife //ll
% svk smerge //mirror/secondlife //myproject/branches/buildfixes
</code>

Since the buildfixes branch changed, you can propagate the changes further to the trunk branch:
<code>
% svk smerge //myproject/branches/buildfixes //myproject/trunk
</code>

And push it to your SVN server:
<code>
% svk smerge //myproject //mirror/myproject
</code>

Source version control

2007-06-19T01:35:30Z

Dale Glass:

Source version control

2007-06-19T01:33:26Z

Dale Glass: Initial draft

Build the Viewer on Linux

2007-06-17T14:11:29Z

Dale Glass: Instructions for Subversion

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

{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

= Building the client =
To build the Second Life Viewer you will first need to install the required tools and libraries.
The following sections online steps to build the client from source. To simplify building,
Linden labs has been nice enough to prepackage some of the libraries and bundled them up in an
additional tar file.

And while The Second Life Viewer is not a trivial build, and experience with building large
software packages will help you greatly - but don't be daunted, it should be simple once the
dependencies are in the right place the first time.

The tasks are:
# Install required tools.
# Unpack source and art tree's from Linden Labs.
# Install libraries not shiped by Linden Labs.
# Unpack or install the other required libraries and headers.
# Compile.
 
 
== Required tools ==
There are a number of tools that need to be installed first.

* SCons build tool [package: scons]
* GCC 3.4 C/C++ compiler [debian/ubuntu: g++-3.4, fedora: compat-gcc-34-c++]; other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without some code adjustments.
* yacc [suggest packages: bison]
* lex [suggest packages: flex]
 
 
== Unpack the source tree ==

You can get the source either from the source archives available at [[Source downloads]], or you can get it from [[Subversion]].

Using a source archive is the easier option, but if you plan to do active development and want to make your own modifications, while merging LL's changes, subversion will probably be much more convenient on the long term.

=== Getting the source from the source archives ===
Get the source from [[Source downloads]]. You will need all 3 archives: source, artwork and libraries.

Choose a location and unpack the source tree and the art work. They will be extracted into a
directory call linden.

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

=== Getting the source from Subversion ===
Select a source [[Source branches|branch]] to check out.

Check it out with:
<code>
% svn co http://svn.secondlife.com/svn/linden/<branch> [directory]
</code>
If you don't specify the directory, it'll use the name of the branch as the default.

Now you will have a directory with the source code. This only includes the source code itself, without the libraries or artwork. You will have to get them from the [[Source downloads]] and unpack them into the tree.

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:
<code>
% ln -sf <branch> linden
</code>

Now unpack the libraries and artwork:
<code>
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>

 

== Installing the required libraries (that Linden labs can not or does not provide)==
=== FMOD (audio) ===
* FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. 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
** Add FMOD=no to your Scons build command when compiling the source.
* If you want to use FMOD, fetch and unpack FMOD 3.75 <http://www.fmod.org/>
<code>
% wget http://www.fmod.org/files/fmodapi375linux.tar.gz
% tar -xzvf fmodapi375linux.tar.gz
% cd fmodapi375linux/
% cp api/inc/* ../linden/libraries/i686-linux/include/
% cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>
 
=== google-perftools (memory checking) ===
* google-perftools library for the tcmalloc and stacktrace libraries.
**[fedora: google-perftools-devel.i386]
**[debian/ubuntu: libgoogle-perftools-dev]
 
 

== Installing the required dependencies (prepackaged by Linden labs)==

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.

<code>
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>
 
=== Doing yourself ===
If you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries. You will have to install the following additional dependencies
listed below. Paths and package names given here are based on Ubuntu 6.06 and may vary
according to your Linux distribution.

==== List of libraries ====
* apr-1 [debian/ubuntu: libapr1.0-dev, fedora: apr-devel]

* aprutil-1 [debian/ubuntu: libaprutil1.0-dev, fedora: apr-util-devel]

* boost [debian/ubuntu: libboost-dev, fedora: boost-devel]

* boost-regex [debian/ubuntu: libboost-regex-dev]

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

* ELFIO <http://sourceforge.net/projects/elfio/>
** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so
<code>
% cd ELFIO && g++-3.4 -shared *.o -o libelfio.so
</code>

* expat [debian/ubuntu: libexpat1-dev, fedora: expat-devel]

* GTK 2.x development headers
** [debian/ubuntu: libgtk2.0-dev
** [fedora: gtk2-devel]

* jpeglib
**[debian/ubuntu: libjpeg62-dev]
**[fedora: libjpeg-devel]

* OpenGL development headers: gl.h, glext.h, glu.h
**[debian/ubuntu: mesa-common-dev, libglu1-mesa-dev]
**[fedora: mesa-libGL-devel, mesa-libGLU-devel]

* OpenJPEG <http://www.openjpeg.org/>
** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
*** ''what does this mean?''
** 02-26-2007, another set of patches is required to Second Life to make it usable, that is fix a crash, make it look good, and speed it up. See https://jira.secondlife.com:443/browse/VWR-123
*** ''VWR-123 has been fixed: should this note be removed?''

* SDL [libsdl1.2-dev, fedora: SDL-devel]

* Vorbis [debian/ubuntu: libvorbis-dev, fedora: libvorbis-devel]

* X11 development headers: Xlib.h, and Xutil.h
**[debian/ubuntu: libx11-dev]
**[fedora: libX11-devel]

* xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
** Apply patches from the instructions in [[patch xmlrpc-epi]]
*** ''does this still work?''
** See also:
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-gcc4.1.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-use-system-expat.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-rename.patch
*** You have to regenerate autotools after applying the patches:
****libtoolize -c -f
****aclocal
****automake -c -a -f
****autoconf
*** The first patch fixes compiling on gcc 4. The second patch causes it to compile against the system expat, the version xmlrpc-epi comes with is broken and will not work. The last patch renames the library from xmlrpc to xmlrpc-epi, otherwise it conflicts with xmlrpc-c - which means the viewer then needs to be patched to link against xmlrpc-epi and not xmlrpc. These patches are from my Fedora package. On linux, I recommend these patches in favor of the Linden ones, as theirs seem to be for windows. (And mine actually work)
 
 

==== Copy headers and libraries into the source tree ====

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.
* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.

You only need to copy the following if you're not using the handy slviewer-linux-libs package:
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include/
 

==== Libs ====

If you are using our easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.
<code>
cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

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

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

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>
 
 

== Compiling ==
=== Build Types ===
The ''BUILD'' parameter specifies the build type. For normal usage, use '''release'''. If you plan to work on the source, choose '''releasenoopt''' or '''debug''', as these versions are unoptimized and much easier to debug.

* '''release''': Optimized build for release.
* '''releasenoopt''': Unoptimized build.
* '''debug''': Debug build with assertions.
* '''releasefordownload''': Optimized build for release, will create a .tar.gz with the files for distribution.
 
=== Building ===
=== Disable llMozLib ===
Add MOZLIB=no to your Scons build command when compiling the source.
 
<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.
 
 
== 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. 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:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
</code>

* 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=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin )
</code>

** For version '''20070117a''' the binary name seems to have changed to '''secondlife-i686-bin-globalsyms''', so the command would be (Tofu Linden says - this was an oversight after a build process change, and future releases will generate a '''secondlife-i686''' again, whereupon this instruction can be removed. :))
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin-globalsyms )
</code>
 
==== Augh!! The client seems REALLY 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. Unfortunately 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 smoother 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 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.

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

==== Automated libraries and headers adjustments, compilation and packaging ====

Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.21 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro. Tested with SL v1.17 sources.

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

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
# Beware: libdb4 makes use of libapr... so you should keep USE_SYSTEM_APR
# and USE_SYSTEM_DB4 in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
USE_SYSTEM_FREETYPE2="yes"
USE_SYSTEM_PERFTOOLS="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp -mtune=athlon-xp"
TUNE_FLAGS="-march=athlon-xp -mtune=athlon-xp"

# Whether to build with the browser login screen or not:
WITH_MOZILLA="yes"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

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

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] && [ "$TEMP_BUILD_DIR" != "" ] && [ "$TEMP_BUILD_DIR" != "/" ] && [ "$TEMP_BUILD_DIR" != "." ] && [ "$TEMP_BUILD_DIR" != ".." ] && [ "$TEMP_BUILD_DIR" != "$HOME" ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

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

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

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

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
sed -e "s/# / /" $TEMP_BUILD_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
#mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

# Missing file... at least in v1.17.
touch $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-O2/-O2 $TUNE_FLAGS/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

compile
</nowiki>
</pre>
</code>
 
 

== FreeBSD ==

A list of patches is given for [[Compiling the viewer (FreeBSD)]].

User:Dale Glass

2007-06-09T23:09:15Z

Dale Glass: jira reporter

Build the Viewer on Linux

2007-06-09T23:06:22Z

Dale Glass: build types

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

== Installing the required dependencies ==

The Second Life Viewer has a number of compile/link dependencies on external libraries which need to be put in place first - 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). The Second Life Viewer is not a trivial build, and experience with building large software packages will help you greatly - but don't be daunted, it should be simple once the dependencies are in the right place the first time.

Paths and package names given here are based on Ubuntu 6.06 and may vary according to your Linux distribution.

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

<code>
unzip slviewer-artwork-<version>.zip
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>

=== Prerequisites ===
{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

* You will need the SCons build tool [package: scons]
* You should use the GCC 3.4 C/C++ compiler [debian/ubuntu: g++-3.4, fedora: compat-gcc-34-c++]; other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without some code adjustments.

* fetch and unpack FMOD 3.75 <http://www.fmod.org/>
** FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. 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
*** Add FMOD=no to your Scons build command when compiling the source.
** If you want to use FMOD:
<code>
wget http://www.fmod.org/files/fmodapi375linux.tar.gz
tar -xzvf fmodapi375linux.tar.gz
cd fmodapi375linux/
cp api/inc/* ../linden/libraries/i686-linux/include/
cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>

* You will need the google-perftools library [fedora: google-perftools-devel.i386] for the tcmalloc and stacktrace libraries.

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

* You will need some development headers for OpenGL and X11: gl.h, glext.h, glu.h, Xlib.h, and Xutil.h [debian/ubuntu: mesa-common-dev, libglu1-mesa-dev, libx11-dev, fedora: mesa-libGL-devel, mesa-libGLU-devel, libX11-devel]

* You will need GTK 2.x development headers [debian/ubuntu: libgtk2.0-dev, fedora: gtk2-devel]

* You will need yacc and lex [suggest packages: bison, flex]

* You may either use our easy slviewer-linux-libs bundle of pre-built libraries and headers unpacked into the Second Life Viewer source tree, or (for example if you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries) you will have to install the following additional dependencies:
** boost [debian/ubuntu: libboost-dev, fedora: boost-devel]
** boost-regex [debian/ubuntu: libboost-regex-dev]
** apr-1 [debian/ubuntu: libapr1.0-dev, fedora: apr-devel]
** aprutil-1 [debian/ubuntu: libaprutil1.0-dev, fedora: apr-util-devel]
** xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
*** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
*** Apply patches from the instructions in [[patch xmlrpc-epi]]
**** ''does this still work?''
** jpeglib [debian/ubuntu: libjpeg62-dev, fedora: libjpeg-devel]
** SDL [libsdl1.2-dev, fedora: SDL-devel]
** Google perftools 0.91 or greater [debian/ubuntu: google-perftools-dev, fedora: google-perftools-devel]
** Vorbis [debian/ubuntu: libvorbis-dev, fedora: libvorbis-devel]
** build ELFIO <http://sourceforge.net/projects/elfio/>
*** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so: <code>cd ELFIO && g++-3.4 -shared *.o -o libelfio.so</code>
** build OpenJPEG <http://www.openjpeg.org/>
*** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
**** ''what does this mean?''
*** 02-26-2007, another set of patches is required to Second Life to make it usable, that is fix a crash, make it look good, and speed it up. See https://jira.secondlife.com:443/browse/VWR-123
**** ''VWR-123 has been fixed: should this note be removed?''
** expat [debian/ubuntu: libexpat1-dev, fedora: expat-devel]

=== Copy headers and libraries into the source tree ===

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.
* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.

You only need to copy the following if you're not using the handy slviewer-linux-libs package:
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include/

If you want to use FMOD ''(this has already been written above)'':
* ${FMOD} refers to the top-level directory into which you unpacked FMOD 3.
cp ${FMOD}/api/inc/* ${SLSRC}/libraries/i686-linux/include/
cp ${FMOD}/api/libfmod-3.75.so ${SLSRC}/libraries/i686-linux/lib_release_client/

=== Disable llMozLib ===

Add MOZLIB=no to your Scons build command when compiling the source.

=== Libs ===

If you are using our easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.
<code>
cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

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

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

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>

== Compiling ==
=== Build Types ===
The ''BUILD'' parameter specifies the build type. For normal usage, use '''release'''. If you plan to work on the source, choose '''releasenoopt''' or '''debug''', as these versions are unoptimized and much easier to debug.

* '''release''': Optimized build for release.
* '''releasenoopt''': Unoptimized build.
* '''debug''': Debug build with assertions.
* '''releasefordownload''': Optimized build for release, will create a .tar.gz with the files for distribution.

=== Building ===
<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.

== 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. 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:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
</code>

* 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=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin )
</code>

** For version '''20070117a''' the binary name seems to have changed to '''secondlife-i686-bin-globalsyms''', so the command would be (Tofu Linden says - this was an oversight after a build process change, and future releases will generate a '''secondlife-i686''' again, whereupon this instruction can be removed. :))
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin-globalsyms )
</code>

==== Augh!! The client seems REALLY 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. Unfortunately 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 smoother 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 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.

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

==== Automated libraries and headers adjustments, compilation and packaging ====

Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.10 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro. Tested with SL v1.17 sources.

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

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
# Beware: libdb4 makes use of libapr... so you should keep USE_SYSTEM_APR
# and USE_SYSTEM_DB4 in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
USE_SYSTEM_FREETYPE2="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp -mtune=athlon-xp"
TUNE_FLAGS=""

# Whether to build with the browser login screen or not:
WITH_MOZILLA="no"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

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

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] && [ "$TEMP_BUILD_DIR" != "" ] && [ "$TEMP_BUILD_DIR" != "/" ] && [ "$TEMP_BUILD_DIR" != "." ] && [ "$TEMP_BUILD_DIR" != ".." ] && [ "$TEMP_BUILD_DIR" != "$HOME" ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

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

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

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

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
sed -e "s/# / /" $TEMP_BUILD_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
#mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

# Missing file... at least in v1.17.
touch $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-O2/-O2 $TUNE_FLAGS/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

compile
</nowiki>
</pre>
</code>

== FreeBSD ==

A list of patches is given for [[Compiling the viewer (FreeBSD)]].

Talk:LlSpeakText

2007-04-05T20:28:13Z

Dale Glass: on the FURRY constants and function arguments

How will this handle unicode characters and languages other then english? [[User:Strife Onizuka|Strife Onizuka]] 11:38, 3 April 2007 (PDT)

The furry variants are just weird. What exactly is a "furry" voice? Such a thing would have to vary depending on species. For instance, snakes and dragons can be considered to be in the furry (doesn't have to be literally furry) category, cats and mice shouldn't sound the same, etc. [[User:Dale Glass|Dale Glass]] 13:28, 5 April 2007 (PDT)

Also, I think the targets list is unnecessary. This would be a local text to speech converter on the user's computer, so a list of targets wouldn't be necessarily as voice wouldn't be streamed: it'd be a normal chat message that'd get converted at the destination. I'd do the function this way: llSpeakText(list params, string text). Besides the voice there are other things that could be interesting to have such as volume, intonation parameters such as speed and pitch, and anything else that might come up. [[User:Dale Glass|Dale Glass]] 13:28, 5 April 2007 (PDT)

Improving compilation time

2007-04-01T15:25:14Z

Dale Glass: Benchmark results and conclusions

== Improving compilation time ==
Based on the benchmarks below, the following conclusions were made:
* The more RAM, the better. Enough RAM will made the hard disk's performance irrelevant.
* Using a RAM disk for /tmp or even the full system doesn't noticeably improve performance if enough RAM is present.
* Given enough RAM, the process will be entirely CPU bound.
* A better hard disk will make a significant difference in link time if enough RAM can't be obtained.
* Compiling using more processes (-j3 vs -j2) may be counterproductive if there's not enough RAM.
* Gentoo compiled 15% faster.
* Gentoo ran scons 50% slower.

== Benchmarks ==

=== Hardware ===
* Athlon 64 X2 5200+ (1MB cache)
* 4GB ECC DDR2 666 RAM
* Root on RAID-1, SAMSUNG HD300LJ and Maxtor 6V300F0

=== Settings ===
* Compiling with -j2
* llmozlib enabled
* building 32 bit SL version
* Source from http://svn.daleglass.net/secondlife, rev 81.

=== Software ===
* Gentoo, x86_64, gcc 4.1.1
* Ubuntu Edgy, x86_64, gcc 4.1.2

=== Methodology ===

Gentoo tests were done with /tmp on tmpfs.

Ubuntu tests were done with the whole install on /tmp on tmpfs, and the whole install on disk. This took about 1.5GB RAM:

* 334MB for temporary files generated during compilation
* 642MB for the source code
* 462MB for the Ubuntu install (probably can be trimmed a bit)

Ubuntu tests were done as follows: Distribution was installed with debootstrap. Sources were copied into it (same copy as used for Gentoo). The whole tree, OS and sources included was copied to /tmp (on tmps), and chrooted into.

The "(on disk)" tests were done afterwards, by copying the whole tree (1.5GB) back to disk (as some changes were required to get the build going).

The "(after reboot)" were done as follows:
# Do required preparations (eg, binary removal)
# Reboot
# Login
# Chroot
# Build

X wasn't running during the tests.

=== Results ===

{|{{Prettytable}}
|+'''Benchmark results'''
|-{{Hl2}}
!Test
!Timings
!Gentoo
!Ubuntu (after reboot)
!Ubuntu (on disk)
!Ubuntu (on RAM disk)
|-
|| Full build || Real || 16m44.594s || 19m23.391s || 19m12.447s || 19m5.572s
|-
|| || User || 29m25.549s || 35m15.595s || 35m23.223s || 35m24.639s
|-
|| || System || 2m57.599s || 2m9.673s || 2m16.113s || 2m13.387s
|-

|| Rebuild || Real || 0m41.752s || 0m27.656s || 0m15.457s || 0m15.444s
|-
|| || User || 0m39.938s || 0m14.858s || 0m14.963s || 0m14.771s
|-
|| || System || 0m1.722s || 0m0.952s || 0m0.644s || 0m0.784s
|-
|| Relink || Real || 1m24.408s || 1m17.616s || 0m41.092s || 0m41.268s
|-
|| || User || 1m12.687s || 0m37.895s || 0m37.455s || 0m38.016s
|-
|| || System || 0m4.599s || 0m4.360s || 0m3.546s || 0m3.258s
|}

Get source and compile

2007-04-01T14:56:44Z

Dale Glass: Added link to Improving compilation time

{{OSWikiContribBox}}

Even if you don't plan to develop, just the act of downloading and compiling can uncover problems. If the version you download doesn't build on your platform, file a bug.

== Getting the source ==
Linden Labs distributes the viewer source code on the [[source downloads]] page. Linden Labs currently does not yet provide public access to a [[version control repository]]. However, there are other websites that do host repositories.

=== Official Downloads ===

Linden Labs does provide current and past downloads in an archived format, see the [[source downloads]] page.

=== OSLCC ===

The OSLCC project has a public Subversion repository hosted on SourceForge with the complete source tree as provided. If you are already familiar with Subversion, here is a list of repositories to the latest versions: (or click to browse)

{|
|Release:
|[http://oslcc.svn.sourceforge.net/viewvc/oslcc/ll/release https://oslcc.svn.sourceforge.net/svnroot/oslcc/ll/release/trunk]
|-
|Focus Beta:
|[http://oslcc.svn.sourceforge.net/viewvc/oslcc/ll/release/branches/1.13.4 https://oslcc.svn.sourceforge.net/svnroot/oslcc/ll/release/branches/1.13.4/trunk]
|-
|First Look:
|[http://oslcc.svn.sourceforge.net/viewvc/oslcc/ll/release/branches/1.14.0 https://oslcc.svn.sourceforge.net/svnroot/oslcc/ll/release/branches/1.14.0/trunk]
|}

=== OpenMetaverse ===

[http://openmetaverse.org OpenMetaverse] hosts an OpenSL project with a public subversion repository.

== Compiling ==

Per platform instructions are available for the following platforms:
* [[Compiling the viewer (MSVS2005)|Microsoft Windows - Visual Studio 2005 & Visual C++ 2005 Express]]
* [[Compiling the viewer (MSVS2003)|Microsoft Windows - Visual Studio .NET 2003]]
** see also: [[Compiling the viewer libraries (MSVS 2003)]]
* [[Cross compiling the viewer (i686-mingw32)|Microsoft Windows - Cross compiling on Linux]]
* [[Compiling the viewer (Mac OS X)|Mac OS X]]
* [[Compiling the viewer (Linux)|Linux]]
* [[Compiling the viewer (FreeBSD)|FreeBSD]]

See [[Common compilation problems]] if you run into errors while building.

See [[Improving compilation time]] for information on how to compile faster

Talk:OpenSource-Dev

2007-03-27T19:43:01Z

Dale Glass: /* The problem: discussion for entertainment purposes */

{{Open Source Talk Page}}

== Mailing list etiquette? ==

As of this moment, there are 387 subscribers to the sldev mailing list. As you would expect with a big public mailing list, most of those people don't post to the list. Of course, a handful of people post a ''lot''. That's ok; if you have something to say, you should say it. However, I also want to make sure that if someone has something to say that everyone needs to read, that it gets read. If there's too much to sort through, that might not happen.

We've discussed the idea that we should split off separate mailing lists. In particular, there are two different proposals:
* {{Jira|MISC-30|alt=sldev-contributors - for those that have signed contribution agreements (MISC-30)}}
* {{Jira|MISC-44|alt=sldev-policy - for legal and policy issues (MISC-44)}}

I've resisted going down that path, because I think that the groupings we want are going to be more fluid than is practical to keep up with (one day we'll want to split off policy, the next day we'll want to split off caching discussions, etc).

I'd like to keep things almost the way that they are, but introduce new guidelines:

* If a topic generates more than five replies in less than 24 hours, it's time to redirect that conversation to one of our other tools, either the wiki or the bug tracker.
* If the topic is not specifically a Second Life development-related topic (e.g. this email, or a licensing discussion), it should be redirected to the wiki or the bug tracker immediately. One post per 48 hours should be sufficient to bring it to everyone's attention.
* If after 48 hours, the topic seems to have died out on the alternate forum, it's ok to reraise the issue on this mailing list, summarizing the offlist conversation thusfar, and calling for further comment in the alternate forum.

I think this policy strikes a good balance between making sure that people have a large forum to raise and discuss a broad spectrum of issues, while at the same time ensuring that the list doesn't become overwhelmed with discussion on a single topic that may not be of interest to everyone on the list.

Thoughts? -- [[User:Rob Linden|Rob Linden]] 10:26, 23 March 2007 (PDT)

:As for the the topics that have done this (moved to the wiki or jira), they have been very successful. I second. [[User:Dzonatas Sol|Dzonatas Sol]] 21:31, 23 March 2007 (PDT)

:Email is obviously a bad idea, but jira/wiki is worse. Forums are the obvious answer to anyone - unless your goal is to put road blocks up before discussion (which certainly makes sense when you want to keep the community from organizing), in which case I suppose this all make sense.

:Jira is for bug reports. Wiki pages are great for documents detailing focused ideas, such as wikipedia entries. But having a dialogue between participants is not what they are meant for. There are no threads, no way to filter, rate participants and find new discussion. The only goal seems to be, as I said above, to keep the community from discussing coherently among themselves.

:What LL is looking for here, let's face it, are people to contribute to their open source project without giving up some kind of control to the community. I'm sure that makes sense to some people around here, but it makes zero sense to me.

:I (and I am sure many others) have avoided contributing to opensim simply because we've been waiting for LL to come around and realise that they need to work with us as a community and not as people to do their singular bidding. In some ways, opensl is becoming a threat to us all, not the opportunity LL wants to make it out to be. The only way to deal with that threat seems to be to work with the opensim crowd and wrench control away rather than work with Linden Lab.

:Is this really what you guys wanted? It certainly isn't what I want. It puts at risk everything I (and everyone else) have tried to build (and we've built a lot for SL. Far more than 95% of your so called open source developers) in secondlife.. but so is the whole direction you're going with OpenSL.

:It's a question of picking our masters - the freedom BSD folks or the "you must GPL everything and you can only talk in jira or wiki folks."

:Pick your poison, I guess. -- {{User|Iron Perth}}

::I don't know why you feel that way so strongly. It is obvious that as an outside developer that communication won't be as easy as being an internal employee. However, there are still features like the [http://forums.secondlife.com/forumdisplay.php?f=296 Technical Talk] area on the forums. Jira issues can easily have forums attached to them; however, the forums are limited to premium users.
::E-Mail is great. The best forum is the modern threaded e-mail unless you are stuck with hotmail or yahoo.
::I'm on a dozen of mail-lists for different projects. SLDev is actually pretty quiet compared to the others, yet the others have "user" lists for the various discussions. [[User:Dzonatas Sol|Dzonatas Sol]] 21:28, 23 March 2007 (PDT)

::----
::I would not object to adding forums as an acceptable conversation redirect target. The reason for directing this conversations to the wiki or jira is to ''help'' the community organize. There is no conspiracy here. I prefer using a wiki talk page so the discussion for a topic is attached directly to the topic itself. So, when newcomers read about a new topic (such as a feature design or these guidelines), they can quickly access the debate about what went into shaping the content of the main page.

::However, if you feel more strongly about using a forum instead, that's fine too. I personally don't think it'll be as effective as the wiki, but I don't mind seeing different experiments. The point is to avoid having huge conversations on the mailing list where no one tries to summarize or capture key ideas. If the goal is discussion for discussion's sake, the status quo would have been just fine. However, I'm assuming that the community wants to accomplish something, so I'm trying to help.

::As I also said before, I think it's fine to raise a topic after a couple of days if the conversation died down before reaching a resolution. I would hope that before reraising it to 380+ people, that someone take the time to actually summarize the conversation and document forward progress. I don't think it's exclusively Linden Lab employees that would appreciate the courtesy. -- [[User:Rob Linden|Rob Linden]] 23:49, 23 March 2007 (PDT)

:----
:I'm not sure if I like this change all that much so far. Moving conversations to the wiki makes things less convenient to discuss, IMO. Now instead of watching my inbox, I've got to use a RSS reader, and subscribe to the feed, but that includes not only the sldev discussion, but also completely unrelated changes such as LSL stuff, and typo corrections. That makes it more effort to keep up with, not less.

:Additionally, there's a loss of functionality in that editing a wiki is less convenient than email. Quoting is harder, formatting requires knowing the wiki syntax with all its conventions, the [[Help:Editing|Editing help]] link leads to a page that's nearly blank, the option of CCing people or not sending a message to the discussion list doesn't exist anymore (maybe userpages, but that's public), and adding something to a wiki requires previewing it first to make sure formatting came out right. There's also the potential problem of conflicting changes to the same page. Also, for some reason, my RSS reader keeps telling me about new entries from yesterday (what's up with that?) that don't appear as the more recent entry, but somewhere in the middle of my list. RSS also slows discussions down, as checking it too frequently places extra load on the server, while IMAP has new mail notification.

:IMO, all of these things are great when they're used for their intended purpose. Mailing lists are good for discussions, keep them for that. Wikis are good for collaborative documetation, but not all that great for discussing. Jira is definitely the right place for bug reporting, but I don't like the idea of discussing anything there. Jira is currently slow, requires logging in, has usability problems (login bug) and doesn't seem to have any sort of reply notification that I can see. -- {{unsigned|Dale Glass}}

::Just had such a 'potential conflict'. Having to merge when wanting to discuss, is, ... well, ... kinda odd. -- [[User:Boroondas Gupte|Boroondas Gupte]] 16:21, 25 March 2007 (PDT)

== Deep linking to conversations ==

Summaries are a fine thing. But, even if a discussion has died out for some while and so was replaced by its summary, you might sometimes wish to search for some single contribution and, once you found it, refer to it. Doing so by links to wiki-diffs of the discussion page's history will be a pain. Is there some better way to do it? I know the question is rather hypothetical right now and could be asked when the problem actually arises, but I think its relevant for the decision of what topic to redirect to what media. -- [[User:Boroondas Gupte|Boroondas Gupte]] 16:16, 25 March 2007 (PDT)

:One way to do it is how I've just done it. Split the conversation into its own thread (with title) and link to it. That means potentially redirecting the context of a quote (admittedly dangerous), but you get a link you can use (e.g. https://wiki.secondlife.com/wiki/Talk:SLDev#Deep_linking_to_conversations ) -- [[User:Rob Linden|Rob Linden]] 17:59, 25 March 2007 (PDT)

== Can things stay organized on a wiki? ==

Although I see the problems of a high traffic mailing list, I share Iron's concerns. Up to now, people discussing on the wiki were very persistent in keeping things formatted and signing their contributions, so you can still see the threads in some way. But can we keep this up as the community is growing? Perhaps someone's got a good idea how this can be made easier, by e.g. a wiki-template generating some thread/tree-like structures with some easy way to answer to a single node.

To ease tracking all discussions on the wiki derived from the mailing list, we could put them in a common category. Any ideas how to name such category? Can someone think of an equivalent for the forums, for jira and the other media where discussions might be redirected to? -- [[User:Boroondas Gupte|Boroondas Gupte]] 16:16, 25 March 2007 (PDT)

:I took the liberty of breaking this into it's own thread, too. I remember hearing about threaded discussions for MediaWiki last year at the Wikimania Hacking Days. I'm not sure if any production-quality software emerged. If someone finds a plugin we can use, I'll look into it (no promises, since I want to make sure I'm introducing something I can commit to support for a while).

:Even without dedicated software, I think the answer is "yes, we can stay organized", or perhaps "yes, we need to stay organized to be effective". It's one thing to make it easy for people writing; more importantly, we all need to make things easy for whoever is going to write the code. I suspect that a lot of people here have the best intentions, and all have valuable opinions of how it should be done, but it won't matter if this dies down a month from now ''unless'' this conversation is in a format that can be easily read and digested. I think what we've created here so far is far more readable than a long mailing list thread.

:Re: category for discussions, I've created a template that I added to this page (<nowiki>{{Open Source Talk Page}}</nowiki>). Please add this talk page to any page you think the group should keep track of this way. -- [[User:Rob Linden|Rob Linden]] 18:32, 25 March 2007 (PDT)
::I'm starting to doubt that. Honestly, the more I use this, the less I like it. Strife has just put Paula's name on something I wrote for some reason, for instance. I'm sure it's a mistake, but really all of this is extra inconvenience for pretty much no gain. Monitoring it is inconvenient. I'm seeing my RSS reader report the same change multiple times now. Now I'm also seeing that I've got to keep watching the page where I wrote something to make sure that what I said isn't misattributed or misrepresented, and that I didn't forget to sign it. Such things aren't a problem for say, documenting LSL, where there shouldn't be such a thing as content ownership in the first place, but it's not good for having a discussion. I can't even be sure that if I decide to forget about this for a few weeks I'll be able to find what I said in the place where I left it. For all I know it might be moved to another section, be archived somewhere, deleted, or moved to another page.

::None of these problems even existed on the mailing list. What I say there will stay in the same place where I wrote it, in the same context, in my exact wording, signed with my GPG key. And there's no reason why I a link to my post from the archive today shouldn't remain valid several years later. Besides, this moving around clearly means that we're already starting to compensate for the deficiencies of the Wiki when used for this purpose. And why are we using a tool that creates extra work instead of avoiding it? [[User:Dale Glass|Dale Glass]] 19:08, 25 March 2007 (PDT)
:::I don't agree with this use of ":" to thread discussion on the talk page. I only use it if it is how the page flows. I suggest to use a template for talk pages that would reformat someones message to look similar to the SL forums "boxed" style. Then we could just wrap our messages up in the template and direct people to use that. [[User:Dzonatas Sol|Dzonatas Sol]] 19:25, 25 March 2007 (PDT)

== Easier for writers vs. easier for readers ==

Okay, I guess things aren't as peachy as I'd hoped. However, I'd like to keep this experiment going for a couple of weeks. In spite of the extra overhead, I think that the result will be something that people will be much more likely to read down the road. I'm assuming that everyone here is writing because they want others to read what they've written (rather than for some therapeutic purpose). In that regard, I believe this method is more effective than the old way. If after two weeks, if I'm the only one who likes this way of doing things, we'll figure out something new.

:Well, it's easier to read, the problem is that it's making it much harder to write, and especially much harder to actively participate. It takes me more time and effort to follow a conversation here. I'm writing here because you asked me to. Obviously, it wouldn't have been much good if I had decided to be a jerk and ignore you completely, or started whining "I don't like it, take it back!" without providing any good reason for it. The longer I post here the more ammunition I can come up with ;-) [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

I have to make clear, though, I really don't think the old status quo was working. I think there was probably a couple dozen really keeping up, and a lot of people who would only read selected messages. I got the sense that some people were trying to dominate the conversation by being the fastest to respond, rather than the most deliberative.

:I'm not sure this is going to help any with that problem. I can still easily post quickly here trying to dominate the conversation, as everybody is slowed down accordingly. I'm not sure that's a good thing either. Why slow things down so that it takes a day to settle an argument when it could be settled in an hour? The longer it takes to discuss, the longer it delays actual coding. [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

Using the wiki as a talk mechanism, I think others a month or two down the road will be much more willing to read the entire [[Talk:Texture cache]] page from start to finish, and absorb the arguments. Whatever replacement we have for this mechanism needs to have similar characteristics. I'm not suggesting we abolish the mailing list for discussion altogether, but rather, just use the wiki when dealing with a hot topic. Let's channel the energy and passion that people have toward the topic to make sure that we end up with a document of lasting value, instead of an endless thread tucked away in a mailing list archive that someone ''may'' find when they plug "texture cache" into their favorite search engine (and, which, even if they find it, they may have no desire to read because it's just too much).

:I see your point, however I don't think this is the right way of dealing with it. If you want to make it easier for newcomers to read, why not try to use some better mailing list archiving software? For example I like Gmane ([http://thread.gmane.org/gmane.linux.kernel/| example here]). Alternatively, use a forum. If going that way, I'd like to see something that supports threads and makes posting code easy.

:The main problem I see with moving active discussions to the wiki is that active discussions are actually more difficult on it. It's strange when we're having a lively discussion on the list, then suddenly we hit the limit, and have to move over to the wiki. It also takes extra effort and slows things down.
:'''<nowiki>[</nowiki>The rest of this answer was moved to its own [[Talk:SLDev#Inworld_discussion_of_hottest_of_hot_topics | subtopic]]<nowiki>]</nowiki>'''

Re: Dale's concern about PGP signatures. I agree that mailing lists are much more effective for PGP sigs. The wiki does at least have the advantage of a complete audit log, but PGP sigs are better. Nonetheless, I think you'll find that getting in the habit of signing comments isn't that tough -- [[User:Rob Linden|Rob Linden]] 22:58, 25 March 2007 (PDT)

:It's not PGP signatures per se that concern me, rather, the difficulty of keeping the integrity of the conversation. If I stay something stupid on the list (which I already have a couple times ;-) it'll stay eternally archived, signed with my key to boot, in the way I said it. But that is fine. I '''did''' say that after all. Meanwhile, here something I said might over time end up somewhere else entirely, and in another context. There's no way to refer to the original and pristine post here, so it can't be 100% sure that what everybody seems to have written is in the context and exact wording it was intended. If we can't be sure that everybody is being represented correctly, having a serious discussion becomes a lot harder [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

===Inworld discussion of hottest of hot topics===
Let me try to propose something new, however: How about we actually use SL for discussions? ;-)
When it becomes clear that the discussion is becoming so heated that we'll end up with a huge long thread people won't want to read, or we're about to start flaming each other, how about we decide to hold an in-world meeting right that moment, discuss whatever needs getting discussed in person and without any delays due to email checking intervals, RSS, etc, reach an agreement (or not), and post a condensed version of the result on the wiki, then link to the full log of the conversation for those who want the gory details? In essence, like SLDev-traffic, but done by the participants (I '''really''' appreciate Soft Noel's contribution here, but I'm not sure how long she'll be able to keep up. This would seem to scale better)

Thus, instead of a 50 posts thread, or a 10 page wiki talk page, we'd have something like this:
After a long in-world discussion (link to full log) between Dale Glass, Strife Onizuka and Paula Innis, consensus was reached that texture caching should be done this way:
(10 lines detailing the mechanism, with links to the appropiate parts of the full talk)
Only thing that might be a problem is that this could seem to exclude people from the discussions, but I'd like to make it clear that my intention here is to take heated disputes between a few participants somewhere they'll get done faster, and when that is settled somebody can always argue with the conclusion. [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

:As inworld discussions lack threads even more than the wiki does and as they tend to move fast, there would be a problem for people who need some time to answer, like me, not being a native speaker (writer?) of English and so needing quite some time to formulate and producing lots of typos that I use to correct before committing my posts. Doing so in a real-time conversation will often lead to the talk having moved to other (sub)topics by the time I have my answer ready. As someone like me you'll have the following options:
:*Keep the answer for yourself, and though not actively participate in the conversation. If the answer is relevant, this might not be a good option.
:*Answer when you got your answer ready, even if the conversation has moved on, and so confusing the other participants and making the log harder to read.
:*Answer right away, not minding formulation and typography, again confusing others and making the log harder to read.
::In-world discussions lack threads, but it's not my intention to say that we should debate everything in-world. But IMO, 20 posts arguing about whether the cache should be stored in one big file or not aren't nearly as interesting as the end result of the discussion. To somebody new, "we agreed on X" is almost certainly more useful. The Wiki seems to me like a great place for documenting things like the results of a discussion, but not nearly as good for actually having one.

::I perfectly understand what you're saying about needing time, btw. English is my third language, and of course some time ago it took me considerable effort to type anything coherent in it. But I'm sure that's not a new thing for people in SL, where there are people from everywhere. Simply say that you need some more to come up with an answer, I'm sure we're not so inconsiderate that we can't wait a bit. I don't know about other people, but when I see people typing I usually wait to see what they say before continuing. [[User:Dale Glass|Dale Glass]] 06:06, 26 March 2007 (PDT)

:Inworld discussions might be good if only some few want to discuss/flame who preferably already know each other well and so can adapt to every one's typing abilities. But as soon as there are more than -- let's say five -- people wanting to participate in a hot discussion who only know each other from their respective wiki and mailing list posts, some slower ones will either be left behind or be forced to (although they might not want to) dominate the discussion to get said what they wanted to say.

::IMO, every medium has good and bad uses. Wikis are good for documenting. Mailing lists are good for long, well thought discussions. If it's the sort of thing where I'd have to read source code, research, etc, or I'm going to announce an idea, a list is the right place. On the other hand, when you get a thread with 2 or 3 people discussing a single subject, and talking to each other, then that's pretty much a conversation, and probably would be best done in-world.

::So, resuming, my overall suggestion would be: Discuss development on the list. If it starts to turn into a long argument between a few people, have them to in-world and argue that there. When a consensus, decision, or interesting point of some sort is made, document it on the wiki. [[User:Dale Glass|Dale Glass]] 06:06, 26 March 2007 (PDT)

:::/me agrees. -- [[User:Boroondas Gupte|Boroondas Gupte]] 07:55, 26 March 2007 (PDT)

:I already experienced that kind of problem in inworld discussions of less relevant (non-Dev) topics, where it normally doesn't matter much which of those (equally bad) options you keep to. And I also know that problem from a reader's POV, having read quite some of the logs of Lindens' office hours I didn't attend.-- [[User:Boroondas Gupte|Boroondas Gupte]] 04:51, 26 March 2007 (PDT)

:Dale Glass's suggestion of utilising in-world conversations to make some level of decisions is probably unworkable as SLDev expands, on the grounds of timezones (let alone diaries!) and lack of wide-spread input due to probably few people being aware of the discussion topic in advnace. Similarly, the use of ":" and multiples for threading is something that clearly works on the large discussions on Wikipedia, etc so can work well for medium-busy discussions, also having the great advantage that everyone will see new ideas pop up on ''recent changes''. Email lists often suffer from subject-lag, but are still useful though tracking back a topic may prove impossible, as are forums with threaded conversations, where at least there is a full record of the discussion. Overall, it is going to depend on the topic, its immediacy-for-decision, and how widespread that discussion needs to reach in terms of interested people, which will make the selection of which communication method to use, not some pre-determined 'all this way or not at all' approach. --[[User:Alison Wheels|Alison Wheels]] 08:57, 26 March 2007 (PDT)

* [[User:Dzonatas Sol|Dzonatas Sol]] writes on 12:16, 26 March 2007 (PDT):
The above conversation with all the mixed levels of tab discussion has just made it harder to read. When you start to insert your paragraph in between the paragraphs of the one before you, it gets much harder to follow. That is what makes wiki's hard to follow. If people follow reply etiquette to thread discussions nicely, it is not that hard. Here, don't interrupt someones reply. Quote and summarized if needed.

As for in-world discussion, main concerns is timezones, reply speed (foreign speakers or office workers), and those that are actually actively coding aren't in-world because they are testing the client.

== The problem: discussion for entertainment purposes ==

I guess this discussion is starting to make me figure out what the real problem is. Here's a couple of totally valid reasons for a long thread:
* Person A, who is committed to write code, asks for discussion about a topic. Much debate ensues, guided by Person A, who is ultimately tasked with writing the code. This may result in Person B and C arguing, but as long as Person A finds the discussion interesting, that's ok.
* Person A, who is committed to write code, states that they are going to do something. Person B doesn't like the approach. Until Person A cuts off the conversation, the thread is probably useful.

Here's what gets tedious:
* Person A, who is not committed to write code, throws out an idea for the list to consider. This provokes much debate among Person B and Person C, neither of whom is interested in committing to the code. So, there's a long debate where Person B and Person C go back and forth, but no one is committed to write code or even document an idea. Nobody is clear on who the audience is.

Most of the arguments about why taking things off list don't work center on the wiki being a poor medium for debate. I suppose it might be, but the question in my mind is "why are we having a debate?" If someone can actually tell me why a debate is important, then I can get behind actually leaving debate open (on the mailing list) on that topic. However, the debates that I've seen lately don't seem to have that characteristic.

So, if directing discussions offlist isn't the answer, what is? Moderate the mailing list? -- [[User:Rob Linden|Rob Linden]] 22:19, 26 March 2007 (PDT)

Tough call. As I said on the list, "If it's not interesting in the absence of immediate feedback, it's probably not worth spending time on... that's a sign you're involved in the discussion rather than the topic." On the other hand, a certain amount of noise on the list probably shouldn't be seen as automatically counterproductive (for example, one thing that I've found immensely useful in following lists and ignoring noise is to subscribe to the list as a digest). On the gripping hand it's the productive individual who gets to make that call as to what's counterproductive.

Partial answer, for people thinking of reading the list: subscribe to a digest, and simply skip digests completely that don't contain any subjects that interest you.

Partial answer for the list manager: can you chunk digests by subject, to make the above easier?

One project I started several years ago was a mailing list archive that dumped each message into a wiki. At the time there wasn't a lot of easily hackable wiki software that could be fed into, so it stalled out. The idea was that you could go in and turn a message into a wiki page, with wiki links between the message and thread and some clever way to add to the page with tags in the email. -- [[User:Argent Stonecutter|Argent Stonecutter]] 10:19, 27 March 2007 (PDT)

:I agree it's a tough call. Part of the reason why I'm making this drive to increase list traffic quality is that I'd like to start heavily advocating more Linden Lab use. One precondition of that is that I have to be able to say, with a straight face, "yes, involvement in this mailing list is a good use of your time". Sure, the [[SLDev Traffic]] summaries are fantastic, but reading that is not the same as being involved with the mailing list. The guidelines I've chosen aren't too different than our own internal communication guidelines, so I believe they will foster the type of involvement I'm hoping for.

: We can put the burden of wheat/chaff sorting on the reader, but given the size of the list, I think it's fair to ask a little more of writers. In exchange for getting a bigger audience, you have to be more considerate of that audience. -- [[User:Rob Linden|Rob Linden]] 10:42, 27 March 2007 (PDT)

:I don't understand how the wiki is supposed to fix that problem. There's absolutely no reason why the tedious exchange you describe above can't happen on the wiki. The only reason I think we're not seeing this sort of thing on the wiki yet is because you step in after it happens on the list, so it stays there. Eventually somebody will start one of those on the wiki. [[User:Dale Glass|Dale Glass]] 12:43, 27 March 2007 (PDT)

== FYI, I'm personally responding to people who post about these guideines on-list ==

I had asked that conversation about the new guidelines occur here, which, unfortunately has caused a discussion to break out on list. Please don't use the list, and please don't reply on-list to those people. I have been (and will continue to) personally reply to those people, rather than replying on list. The people who are interested and/or need to participate in this conversation are right here. I suspect that most people did not sign up for sldev to keep abreast of tedious mailing list policy questions, so please be courteous to those people. Thanks -- [[User:Rob Linden|Rob Linden]] 11:22, 27 March 2007 (PDT)

== Conversations that span years ==

One thing that people who don't have a lot of wiki experience may not understand about conversations on wikis is that, unlike mailing list conversations, they can span weeks, months or even years, as opposed to mailing list conversations that rarely live past a week or so of inactivity. For design discussions, this is a really important attribute. It helps us develop a better collective memory of what we've discussed and what we haven't, and makes it much quicker for people to come up to speed.

Because this benefit isn't immediately apparent, I really need to call this out. Please be patient. A few months from now, when everyone here is sick of the current topic, and when someone asks "has anyone considered using Berkeley DB for texture caches?", you'll be able to say "[[Talk:Texture cache|yes we did]]", and redirect the conversation to the wiki -- [[User:Rob Linden|Rob Linden]] 11:28, 27 March 2007 (PDT)

Talk:OpenSource-Dev

2007-03-26T13:06:13Z

Dale Glass: /* Inworld discussion of hottest of hot topics */

{{Open Source Talk Page}}

== Mailing list etiquette? ==

As of this moment, there are 387 subscribers to the sldev mailing list. As you would expect with a big public mailing list, most of those people don't post to the list. Of course, a handful of people post a ''lot''. That's ok; if you have something to say, you should say it. However, I also want to make sure that if someone has something to say that everyone needs to read, that it gets read. If there's too much to sort through, that might not happen.

We've discussed the idea that we should split off separate mailing lists. In particular, there are two different proposals:
* {{Jira|MISC-30|alt=sldev-contributors - for those that have signed contribution agreements (MISC-30)}}
* {{Jira|MISC-44|alt=sldev-policy - for legal and policy issues (MISC-44)}}

I've resisted going down that path, because I think that the groupings we want are going to be more fluid than is practical to keep up with (one day we'll want to split off policy, the next day we'll want to split off caching discussions, etc).

I'd like to keep things almost the way that they are, but introduce new guidelines:

* If a topic generates more than five replies in less than 24 hours, it's time to redirect that conversation to one of our other tools, either the wiki or the bug tracker.
* If the topic is not specifically a Second Life development-related topic (e.g. this email, or a licensing discussion), it should be redirected to the wiki or the bug tracker immediately. One post per 48 hours should be sufficient to bring it to everyone's attention.
* If after 48 hours, the topic seems to have died out on the alternate forum, it's ok to reraise the issue on this mailing list, summarizing the offlist conversation thusfar, and calling for further comment in the alternate forum.

I think this policy strikes a good balance between making sure that people have a large forum to raise and discuss a broad spectrum of issues, while at the same time ensuring that the list doesn't become overwhelmed with discussion on a single topic that may not be of interest to everyone on the list.

Thoughts? -- [[User:Rob Linden|Rob Linden]] 10:26, 23 March 2007 (PDT)

:As for the the topics that have done this (moved to the wiki or jira), they have been very successful. I second. [[User:Dzonatas Sol|Dzonatas Sol]] 21:31, 23 March 2007 (PDT)

:Email is obviously a bad idea, but jira/wiki is worse. Forums are the obvious answer to anyone - unless your goal is to put road blocks up before discussion (which certainly makes sense when you want to keep the community from organizing), in which case I suppose this all make sense.

:Jira is for bug reports. Wiki pages are great for documents detailing focused ideas, such as wikipedia entries. But having a dialogue between participants is not what they are meant for. There are no threads, no way to filter, rate participants and find new discussion. The only goal seems to be, as I said above, to keep the community from discussing coherently among themselves.

:What LL is looking for here, let's face it, are people to contribute to their open source project without giving up some kind of control to the community. I'm sure that makes sense to some people around here, but it makes zero sense to me.

:I (and I am sure many others) have avoided contributing to opensim simply because we've been waiting for LL to come around and realise that they need to work with us as a community and not as people to do their singular bidding. In some ways, opensl is becoming a threat to us all, not the opportunity LL wants to make it out to be. The only way to deal with that threat seems to be to work with the opensim crowd and wrench control away rather than work with Linden Lab.

:Is this really what you guys wanted? It certainly isn't what I want. It puts at risk everything I (and everyone else) have tried to build (and we've built a lot for SL. Far more than 95% of your so called open source developers) in secondlife.. but so is the whole direction you're going with OpenSL.

:It's a question of picking our masters - the freedom BSD folks or the "you must GPL everything and you can only talk in jira or wiki folks."

:Pick your poison, I guess. -- {{User|Iron Perth}}

::I don't know why you feel that way so strongly. It is obvious that as an outside developer that communication won't be as easy as being an internal employee. However, there are still features like the [http://forums.secondlife.com/forumdisplay.php?f=296 Technical Talk] area on the forums. Jira issues can easily have forums attached to them; however, the forums are limited to premium users.
::E-Mail is great. The best forum is the modern threaded e-mail unless you are stuck with hotmail or yahoo.
::I'm on a dozen of mail-lists for different projects. SLDev is actually pretty quiet compared to the others, yet the others have "user" lists for the various discussions. [[User:Dzonatas Sol|Dzonatas Sol]] 21:28, 23 March 2007 (PDT)

::----
::I would not object to adding forums as an acceptable conversation redirect target. The reason for directing this conversations to the wiki or jira is to ''help'' the community organize. There is no conspiracy here. I prefer using a wiki talk page so the discussion for a topic is attached directly to the topic itself. So, when newcomers read about a new topic (such as a feature design or these guidelines), they can quickly access the debate about what went into shaping the content of the main page.

::However, if you feel more strongly about using a forum instead, that's fine too. I personally don't think it'll be as effective as the wiki, but I don't mind seeing different experiments. The point is to avoid having huge conversations on the mailing list where no one tries to summarize or capture key ideas. If the goal is discussion for discussion's sake, the status quo would have been just fine. However, I'm assuming that the community wants to accomplish something, so I'm trying to help.

::As I also said before, I think it's fine to raise a topic after a couple of days if the conversation died down before reaching a resolution. I would hope that before reraising it to 380+ people, that someone take the time to actually summarize the conversation and document forward progress. I don't think it's exclusively Linden Lab employees that would appreciate the courtesy. -- [[User:Rob Linden|Rob Linden]] 23:49, 23 March 2007 (PDT)

:----
:I'm not sure if I like this change all that much so far. Moving conversations to the wiki makes things less convenient to discuss, IMO. Now instead of watching my inbox, I've got to use a RSS reader, and subscribe to the feed, but that includes not only the sldev discussion, but also completely unrelated changes such as LSL stuff, and typo corrections. That makes it more effort to keep up with, not less.

:Additionally, there's a loss of functionality in that editing a wiki is less convenient than email. Quoting is harder, formatting requires knowing the wiki syntax with all its conventions, the [[Help:Editing|Editing help]] link leads to a page that's nearly blank, the option of CCing people or not sending a message to the discussion list doesn't exist anymore (maybe userpages, but that's public), and adding something to a wiki requires previewing it first to make sure formatting came out right. There's also the potential problem of conflicting changes to the same page. Also, for some reason, my RSS reader keeps telling me about new entries from yesterday (what's up with that?) that don't appear as the more recent entry, but somewhere in the middle of my list. RSS also slows discussions down, as checking it too frequently places extra load on the server, while IMAP has new mail notification.

:IMO, all of these things are great when they're used for their intended purpose. Mailing lists are good for discussions, keep them for that. Wikis are good for collaborative documetation, but not all that great for discussing. Jira is definitely the right place for bug reporting, but I don't like the idea of discussing anything there. Jira is currently slow, requires logging in, has usability problems (login bug) and doesn't seem to have any sort of reply notification that I can see. -- {{unsigned|Dale Glass}}

::Just had such a 'potential conflict'. Having to merge when wanting to discuss, is, ... well, ... kinda odd. -- [[User:Boroondas Gupte|Boroondas Gupte]] 16:21, 25 March 2007 (PDT)

== Deep linking to conversations ==

Summaries are a fine thing. But, even if a discussion has died out for some while and so was replaced by its summary, you might sometimes wish to search for some single contribution and, once you found it, refer to it. Doing so by links to wiki-diffs of the discussion page's history will be a pain. Is there some better way to do it? I know the question is rather hypothetical right now and could be asked when the problem actually arises, but I think its relevant for the decision of what topic to redirect to what media. -- [[User:Boroondas Gupte|Boroondas Gupte]] 16:16, 25 March 2007 (PDT)

:One way to do it is how I've just done it. Split the conversation into its own thread (with title) and link to it. That means potentially redirecting the context of a quote (admittedly dangerous), but you get a link you can use (e.g. https://wiki.secondlife.com/wiki/Talk:SLDev#Deep_linking_to_conversations ) -- [[User:Rob Linden|Rob Linden]] 17:59, 25 March 2007 (PDT)

== Can things stay organized on a wiki? ==

Although I see the problems of a high traffic mailing list, I share Iron's concerns. Up to now, people discussing on the wiki were very persistent in keeping things formatted and signing their contributions, so you can still see the threads in some way. But can we keep this up as the community is growing? Perhaps someone's got a good idea how this can be made easier, by e.g. a wiki-template generating some thread/tree-like structures with some easy way to answer to a single node.

To ease tracking all discussions on the wiki derived from the mailing list, we could put them in a common category. Any ideas how to name such category? Can someone think of an equivalent for the forums, for jira and the other media where discussions might be redirected to? -- [[User:Boroondas Gupte|Boroondas Gupte]] 16:16, 25 March 2007 (PDT)

:I took the liberty of breaking this into it's own thread, too. I remember hearing about threaded discussions for MediaWiki last year at the Wikimania Hacking Days. I'm not sure if any production-quality software emerged. If someone finds a plugin we can use, I'll look into it (no promises, since I want to make sure I'm introducing something I can commit to support for a while).

:Even without dedicated software, I think the answer is "yes, we can stay organized", or perhaps "yes, we need to stay organized to be effective". It's one thing to make it easy for people writing; more importantly, we all need to make things easy for whoever is going to write the code. I suspect that a lot of people here have the best intentions, and all have valuable opinions of how it should be done, but it won't matter if this dies down a month from now ''unless'' this conversation is in a format that can be easily read and digested. I think what we've created here so far is far more readable than a long mailing list thread.

:Re: category for discussions, I've created a template that I added to this page (<nowiki>{{Open Source Talk Page}}</nowiki>). Please add this talk page to any page you think the group should keep track of this way. -- [[User:Rob Linden|Rob Linden]] 18:32, 25 March 2007 (PDT)
::I'm starting to doubt that. Honestly, the more I use this, the less I like it. Strife has just put Paula's name on something I wrote for some reason, for instance. I'm sure it's a mistake, but really all of this is extra inconvenience for pretty much no gain. Monitoring it is inconvenient. I'm seeing my RSS reader report the same change multiple times now. Now I'm also seeing that I've got to keep watching the page where I wrote something to make sure that what I said isn't misattributed or misrepresented, and that I didn't forget to sign it. Such things aren't a problem for say, documenting LSL, where there shouldn't be such a thing as content ownership in the first place, but it's not good for having a discussion. I can't even be sure that if I decide to forget about this for a few weeks I'll be able to find what I said in the place where I left it. For all I know it might be moved to another section, be archived somewhere, deleted, or moved to another page.

::None of these problems even existed on the mailing list. What I say there will stay in the same place where I wrote it, in the same context, in my exact wording, signed with my GPG key. And there's no reason why I a link to my post from the archive today shouldn't remain valid several years later. Besides, this moving around clearly means that we're already starting to compensate for the deficiencies of the Wiki when used for this purpose. And why are we using a tool that creates extra work instead of avoiding it? [[User:Dale Glass|Dale Glass]] 19:08, 25 March 2007 (PDT)
:::I don't agree with this use of ":" to thread discussion on the talk page. I only use it if it is how the page flows. I suggest to use a template for talk pages that would reformat someones message to look similar to the SL forums "boxed" style. Then we could just wrap our messages up in the template and direct people to use that. [[User:Dzonatas Sol|Dzonatas Sol]] 19:25, 25 March 2007 (PDT)

== Easier for writers vs. easier for readers ==

Okay, I guess things aren't as peachy as I'd hoped. However, I'd like to keep this experiment going for a couple of weeks. In spite of the extra overhead, I think that the result will be something that people will be much more likely to read down the road. I'm assuming that everyone here is writing because they want others to read what they've written (rather than for some therapeutic purpose). In that regard, I believe this method is more effective than the old way. If after two weeks, if I'm the only one who likes this way of doing things, we'll figure out something new.

:Well, it's easier to read, the problem is that it's making it much harder to write, and especially much harder to actively participate. It takes me more time and effort to follow a conversation here. I'm writing here because you asked me to. Obviously, it wouldn't have been much good if I had decided to be a jerk and ignore you completely, or started whining "I don't like it, take it back!" without providing any good reason for it. The longer I post here the more ammunition I can come up with ;-) [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

I have to make clear, though, I really don't think the old status quo was working. I think there was probably a couple dozen really keeping up, and a lot of people who would only read selected messages. I got the sense that some people were trying to dominate the conversation by being the fastest to respond, rather than the most deliberative.

:I'm not sure this is going to help any with that problem. I can still easily post quickly here trying to dominate the conversation, as everybody is slowed down accordingly. I'm not sure that's a good thing either. Why slow things down so that it takes a day to settle an argument when it could be settled in an hour? The longer it takes to discuss, the longer it delays actual coding. [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

Using the wiki as a talk mechanism, I think others a month or two down the road will be much more willing to read the entire [[Talk:Texture cache]] page from start to finish, and absorb the arguments. Whatever replacement we have for this mechanism needs to have similar characteristics. I'm not suggesting we abolish the mailing list for discussion altogether, but rather, just use the wiki when dealing with a hot topic. Let's channel the energy and passion that people have toward the topic to make sure that we end up with a document of lasting value, instead of an endless thread tucked away in a mailing list archive that someone ''may'' find when they plug "texture cache" into their favorite search engine (and, which, even if they find it, they may have no desire to read because it's just too much).

:I see your point, however I don't think this is the right way of dealing with it. If you want to make it easier for newcomers to read, why not try to use some better mailing list archiving software? For example I like Gmane ([http://thread.gmane.org/gmane.linux.kernel/| example here]). Alternatively, use a forum. If going that way, I'd like to see something that supports threads and makes posting code easy.

:The main problem I see with moving active discussions to the wiki is that active discussions are actually more difficult on it. It's strange when we're having a lively discussion on the list, then suddenly we hit the limit, and have to move over to the wiki. It also takes extra effort and slows things down.
:'''<nowiki>[</nowiki>The rest of this answer was moved to its own [[Talk:SLDev#Inworld_discussion_of_hottest_of_hot_topics | subtopic]]<nowiki>]</nowiki>'''

Re: Dale's concern about PGP signatures. I agree that mailing lists are much more effective for PGP sigs. The wiki does at least have the advantage of a complete audit log, but PGP sigs are better. Nonetheless, I think you'll find that getting in the habit of signing comments isn't that tough -- [[User:Rob Linden|Rob Linden]] 22:58, 25 March 2007 (PDT)

:It's not PGP signatures per se that concern me, rather, the difficulty of keeping the integrity of the conversation. If I stay something stupid on the list (which I already have a couple times ;-) it'll stay eternally archived, signed with my key to boot, in the way I said it. But that is fine. I '''did''' say that after all. Meanwhile, here something I said might over time end up somewhere else entirely, and in another context. There's no way to refer to the original and pristine post here, so it can't be 100% sure that what everybody seems to have written is in the context and exact wording it was intended. If we can't be sure that everybody is being represented correctly, having a serious discussion becomes a lot harder [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

===Inworld discussion of hottest of hot topics===
Let me try to propose something new, however: How about we actually use SL for discussions? ;-)
When it becomes clear that the discussion is becoming so heated that we'll end up with a huge long thread people won't want to read, or we're about to start flaming each other, how about we decide to hold an in-world meeting right that moment, discuss whatever needs getting discussed in person and without any delays due to email checking intervals, RSS, etc, reach an agreement (or not), and post a condensed version of the result on the wiki, then link to the full log of the conversation for those who want the gory details? In essence, like SLDev-traffic, but done by the participants (I '''really''' appreciate Soft Noel's contribution here, but I'm not sure how long she'll be able to keep up. This would seem to scale better)

Thus, instead of a 50 posts thread, or a 10 page wiki talk page, we'd have something like this:
After a long in-world discussion (link to full log) between Dale Glass, Strife Onizuka and Paula Innis, consensus was reached that texture caching should be done this way:
(10 lines detailing the mechanism, with links to the appropiate parts of the full talk)
Only thing that might be a problem is that this could seem to exclude people from the discussions, but I'd like to make it clear that my intention here is to take heated disputes between a few participants somewhere they'll get done faster, and when that is settled somebody can always argue with the conclusion. [[User:Dale Glass|Dale Glass]] 03:29, 26 March 2007 (PDT)

:As inworld discussions lack threads even more than the wiki does and as they tend to move fast, there would be a problem for people who need some time to answer, like me, not being a native speaker (writer?) of English and so needing quite some time to formulate and producing lots of typos that I use to correct before committing my posts. Doing so in a real-time conversation will often lead to the talk having moved to other (sub)topics by the time I have my answer ready. As someone like me you'll have the following options:
:*Keep the answer for yourself, and though not actively participate in the conversation. If the answer is relevant, this might not be a good option.
:*Answer when you got your answer ready, even if the conversation has moved on, and so confusing the other participants and making the log harder to read.
:*Answer right away, not minding formulation and typography, again confusing others and making the log harder to read.
::In-world discussions lack threads, but it's not my intention to say that we should debate everything in-world. But IMO, 20 posts arguing about whether the cache should be stored in one big file or not aren't nearly as interesting as the end result of the discussion. To somebody new, "we agreed on X" is almost certainly more useful. The Wiki seems to me like a great place for documenting things like the results of a discussion, but not nearly as good for actually having one.

::I perfectly understand what you're saying about needing time, btw. English is my third language, and of course some time ago it took me considerable effort to type anything coherent in it. But I'm sure that's not a new thing for people in SL, where there are people from everywhere. Simply say that you need some more to come up with an answer, I'm sure we're not so inconsiderate that we can't wait a bit. I don't know about other people, but when I see people typing I usually wait to see what they say before continuing. [[User:Dale Glass|Dale Glass]] 06:06, 26 March 2007 (PDT)

:Inworld discussions might be good if only some few want to discuss/flame who preferably already know each other well and so can adapt to every one's typing abilities. But as soon as there are more than -- let's say five -- people wanting to participate in a hot discussion who only know each other from their respective wiki and mailing list posts, some slower ones will either be left behind or be forced to (although they might not want to) dominate the discussion to get said what they wanted to say.

::IMO, every medium has good and bad uses. Wikis are good for documenting. Mailing lists are good for long, well thought discussions. If it's the sort of thing where I'd have to read source code, research, etc, or I'm going to announce an idea, a list is the right place. On the other hand, when you get a thread with 2 or 3 people discussing a single subject, and talking to each other, then that's pretty much a conversation, and probably would be best done in-world.

::So, resuming, my overall suggestion would be: Discuss development on the list. If it starts to turn into a long argument between a few people, have them to in-world and argue that there. When a consensus, decision, or interesting point of some sort is made, document it on the wiki. [[User:Dale Glass|Dale Glass]] 06:06, 26 March 2007 (PDT)

:I already experienced that kind of problem in inworld discussions of less relevant (non-Dev) topics, where it normally doesn't matter much which of those (equally bad) options you keep to. And I also know that problem from a reader's POV, having read quite some of the logs of Lindens' office hours I didn't attend.-- [[User:Boroondas Gupte|Boroondas Gupte]] 04:51, 26 March 2007 (PDT)