Second Life Wiki - User contributions [en]

Talk:Capabilities

2007-12-13T14:56:18Z

Hunting Hare: Request more info re: capabilities and what operations rely on them

There isn't enough documentation here.

What capabilities exist? What capabilities can be requested? What operations depend on a capability being requested/active? [[User:Hunting Hare|Hunting Hare]] 06:56, 13 December 2007 (PST)

User talk:Tedd Maa/stand-alone script engine

2007-11-11T02:55:33Z

Hunting Hare: Reminding of the need to apply the same rigorous forms of validation to server-remote ScriptEngine connections as to scripts running server-local.

* Although this is interesting Tedd, it doesn't seem to keep in mind one very fundamental issue: computations at the server end have limited scalability, relative to any of the pressure points on scaling, which all derive from population pressure in one way or another. No matter how we partition computing resources server-side, there will always be a key computational workload there for physics etc, so in general there is only limited power left over for ambitious scripting. While we'd all like high-powered in-world scripting, that's just not going to happen as long as the only available computing horsepower for scripting is server-side.

* Although it's not going to happen for a long time, relatively unlimited scripting power is ultimately going to have to come by harnessing the clients, through server-side orchestration of partitioned tasks distributed very dynamically across all connected participants. This is the '''only''' source of computing power that both scales with population and offers massive resource per leaf node. What's more, with multicore CPUs everywhere (and with very little work for them to do because desktop apps tend not to be structured for parallelism), this is one resource that has a very bright future.

* So, while you offer some interesting things to think about here, if you want to look ahead to a future of high-powered server-side scripting, you really need to think about workload offloading too. (That's still "server-side scripting", even though the computations are distributed and run client-side, because such computations can never under any circumstances affect the client state; "client-side scripting" is a different matter altogether.) --[[User:Morgaine Dinova|Morgaine Dinova]] 04:18, 15 October 2007 (PDT)

----

[[User:Tedd Maa|Tedd Maa]]: In reply to the points by Morgaine.

* There are limitations on the server side, yes. But this does not mean we should purposely design the scripting system in a bad way. It is up to the server itself to scale physics well. But the script engine is not limited to controlling physical objects. It can be clouds, smoke or even gameplay rules that don't even exist as an object in the world.

* The whole point of this design is to be able to run scripts from anywhere. For example from the client. But running it from the client breaks persistency in the world. When user logs off, objects disappear. So I imagine people who want to run their own script engine having a shell somewhere like we did back in the 90's with good old bots and bouncers on IRC. But your script can very well be bound to a script engine embedded in your SL viewer for example, no problem. The region server doesn't need to discriminate on who is running the script server if server admin doesn't want it to.

* It is still ''called'' server-side scripting. But one single script (or multiple scripts) can be any program in any programming language running on any number of computers on any number of different operating systems and CPUs anywhere in the world. As long as the region has only ONE endpoint to speak to it does not discriminate on implementation, operating system, number of computers involved in computation, etc. This is the whole essence of my plan. I will look through the document and see if maybe I didn't communicate that clearly enough. Its still just a first draft.

[[User:Tedd Maa|Tedd Maa]] 20071015 16:40 UTC/GMT+1

== Object Orientated Program Environment ==

Most traditional OOP languages fall short of the object orientated design. That is they call themselves a object-oriented program language, but they are not much of a object orientated approach outside of the language itself. Notice how I use "oriented" and "orientated." One leans towards the paradigm from the outside and the other is centered in the entire paradigm and works outward. At first glance of the your plan I heard a familiar tune, and it matches with the object-oriented program languages. Such languages have been quite a step in the industry, but they have been pushed out to market before their maturity.

As you can see from my post about "[[User:Dzonatas Sol|Client Script & Persistent Data Object]]," one of the ideas here is similar. In fact, the entire concept you have presented so far can be summed up underneath paravirtual machines. On that point, to call this "Tedds stand-alone script engine" may do some injustice to those who might want to contribute to the development of this project.

Another point, the security has to go much deeper than what I see talked about in the article. To offset the execute state to a different physical area is not enough, for example. We need to be able to run arbitrary code in arbitrary locations.

I stay focused on the object-orientated environments, and I hope you follow if you continue such motives to rewrite the engine. [[User:Dzonatas Sol|Dzonatas Sol]] 12:31, 15 October 2007 (PDT)

----

good point on the "Tedds stand-alone script engine" - wasn't meant to name it at all, was meant as "Tedds proposal on ..." or "Tedds discussion on ...". I will fix that in next revision (hopefully coming in a couple of days).

Security is something I'm still thinking about. I'll try to get something more about that into next revision.
(security always comes first, so it will probably dictate some of the details in the design)

[[User:Tedd Maa|Tedd Maa]] 20071016 21:50 UTC/GMT+1

----

I've got a few things to say, as someone who's implemented and dealt with scripting under MUDs. What I'm going to say may fly in the face of what you recognize is true, but it's important to recognize some of what has been dealt with.

First, there is literally no difference between the effect of running a script on the server itself and the effect of running it somewhere else. They are functionally and from a security context identical -- which means that you can't state that simply running it on a different server, or in a different process, or anything is going to improve security. The reason why is because the server must trust the script-RPC input enough to allow the state changes that the script requests to occur within its (authoritative) view of the world.

This means that the effects that the ScriptEngine is requesting must be granted privilege if the Script running in the ScriptEngine is to effect any changes in the persistent world.

The only effective difference between running the ScriptEngine on the server and running it on the client (or somewhere else referenced by the client) is that the ScriptEngine running on the server can be vetted as to its possible impact by the server operator. It's MUCH harder to verify a new protocol that submits requested changes than to verify source that implements the protocol. (If the sim is running on a low-powered machine, the external scripting engine could conceivably overwhelm it with events unless it's carefully throttled.)

A local ScriptEngine can enforce requirements, can enforce how quickly a script is allowed to execute its next instructions, and can much more easily manage things. As well, a local ScriptEngine can enforce its own security boundary by preventing access to P/Invoke or any of a number of other dangerous functions and objects. It can also verify the code the same way that the CLR does to ensure that it doesn't call anything that isn't acceptable. A local ScriptEngine could accept CLR bytecode (though it doesn't have to). It could accept things written in LSL1 or anything, compile them to MSIL, and run them.

Technically, a server operator doesn't need to allow any external ScriptEngines -- and I would argue that not allowing it is the most secure option (to minimize attack surface). Thus, I'm going to make a new proposal...

Every grid's operation staff (even if it's a staff of one) is god, within that grid. They rather have to be (by definition, they're the operations staff that implements the grid policy). That means that they must be able to grant or restrict access to any function of the grid's implementing servers, including server scripting, server-remote scripting, and each and every function that could be called. They need to be able to limit the number of instructions that a script can run, they need to be able to implement their own concepts of "ownership" and "permissions"... and as such, they need to be able to have a death-grip on the code that they allow to run. (This means that they must be able to have more granularity than simply saying 'llPushObject not allowed in this parcel'.)

So, I propose a privilege-based and privilege-mandated system. Allowing users to run scripts on the server is fine -- as long as you don't try to retrofit a security policy onto a code base that doesn't support it. The initial design must include the means to grant or deny permissions on an individual function level -- and must also include the means to create "groups" of permissions that can be granted in toto to a user. Another important design requirement is that a single function can belong to more than one group -- so that (for example) functions which are string handling utilities can be assigned to both the 'stringhandling' and the 'remoteHTTP' groups.

All decision on whether to grant the privilege needs to be made before the function does any processing -- which means that every function must, before anything else, check its authority to run that command. (This is the same thing that would be necessary for any implementation of server-remote ScriptEngines, on each and every message.) There are ways to optimize this, of course -- keeping a hash of functions that have been verified as having been given permission to run so the security manager doesn't need to do much more time-consuming privilege lookups on every function call is a good way of doing it -- but it still must be done.

This is not to say that the idea of a remote ScriptServer is bad -- it would be very useful, for those who would otherwise run afoul of (say) XMLRPC connection throttling, they can just do it from their own system and not worry about it. It just has to be done very carefully, and the incoming request validator needs to operate with the same level of rigorous input validation that would otherwise be applied to user scripts running on the server.

(And as for 'persistence' in the world... the only time you can have persistence is if the grid operator agrees to do everything it can to make the world actually persistent, including accept uploads to its asset server and require no state to be saved on the client. I'm a very big fan of allowing (or, in some contexts, requiring) the user to 'pay his own way' in terms of asset storage -- if the user stops participating in a world, eventually the data expires from the grid's asset cache and stops showing up in the world until the next time the user logs in and retransfers the assets from local to gridcache. Because it wouldn't take up assetserver space indefinitely, it would also reduce the need to charge L$ for texture and animation uploads. Unless that's a very large part of LL's reduction of L$ in the economy, it's not necessary and it only provides a barrier to entry. Play for free, but if you want to create? You gotta pay.)

[[User:Hunting Hare|Hunting Hare]] 18:55, 10 November 2007 (PST)

Talk:Compiling the viewer (Mac OS X)

2007-04-09T19:06:03Z

Hunting Hare: /* PLEASE NOTE */ Added info about GCC 3.3 not working for Intel-based Macs

{{Open Source Talk Page}}

==PLEASE NOTE==

When you report any problem, PLEASE post your OS version and version of Xcode. This will help identify the environments that have issues, and allow the creation of workarounds specific to those environments. Thank you! [[User:Hunting Hare|Hunting Hare]] 01:36, 15 January 2007 (PST)

In addition, please post the name and version number of what you're compiling. This helps us figure out if there are problems introduced from an older version to a newer version.

GCC 3.3 DOES NOT TARGET INTEL-BASED MACS. If you are targeting an Intel-based Mac, you MUST use GCC 4.0. There are known incompatibilities between gcc 3.3 and gcc 4.0 (some code that compiles on 3.3 won't compile under 4.0). Apple recommends that all projects migrate to gcc 4.0 as soon as practical, for PPC as well as Intel architectures.

At this time, if you use the precompiled libraries package, the macview source can compile and be linked using gcc 4.0. I have not verified the build processes for all of the dependent libraries yet.

Thank you for your attention! [[User:Hunting Hare|Hunting Hare]] 12:06, 9 April 2007 (PDT)

==Ordering of main and proprietary material installs ==
I suggest the section "Installing Proprietary Libraries" should come after the sections "Installing Libraries" and "Installing Libraries From Scratch", as the instructions on fmod installation require that the main directory structure has been established. I'm just looking at the material for the first time, so I won't do the move myself in case I'm missing something. --[[User:Bram Nogah|Bram Nogah]] 15:59, 17 February 2007 (PST)

I thought the same thing also, I left the "Installing Proprietary Libraries" before "Installing Libraries as like an intro, then I moved the "Fmod" section after the section "Installing Libraries From Scratch" and before the "Boost" section --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 04:53, 7 April 2007 (PDT)

==Mozilla==

I'm a bit confused about the Mozilla lib dependency--perhaps if someone knew what was actually required to be compiled (even if it would be somewhat difficult) we could at least try. :-) Thanks. [[User:David Frantisek|David Frantisek]] 19:55, 8 January 2007 (PST)

In the third step i'm getting a "checking for C compiler default output file name... configure: error: C compiler cannot create executables". I found out that is because i'm using an intel mac. Switching to GCC 4.0.1 does the trick [[User:Eelke Forder | Eelke Folmer]]

==Problems with directions==

It seems like there are a couple places here where problems are created because of the use of "../.." I'm not all that familiar with use of the terminal, but I think this puts you in your home directory, which is okay as long as that's the top-level of your project, but not if the top-level is ~/Desktop or somewhere else entirely. [[User:David Frantisek|David Frantisek]] 19:55, 8 January 2007 (PST)

''../.. refers to the parent of the parent folder -- from /Users/yourusername/ , ../.. would refer to the root directory that contains the Users folder. Remember, Mac OS X has the technological underpinning of BSD UNIX. If you're not familiar with the use of the Terminal, then you will likely find a book on using UNIX very helpful. For reference, the single character ~ refers to your home directory but only if it's used as the first element of a path specification -- ~/Desktop refers to your Desktop folder. ~username/ refers to the home directory of username. [[User:Hunting Hare|Hunting Hare]] 01:36, 15 January 2007 (PST)''

==XMLRPC==
- Applied patches as prescribed but after doing the final make I get: "configure: error: libexpat not found make: *** [config.status] Error 1" I can't compile using GCC 3.3 [[User:Eelke Forder|Eelke Folmer]] GCC 4.0.0 / OSX 10.4.9
- When I apply patch 3 i get: Hunk #1 succeeded at 120 (offset -1 lines).

- I get same error using gcc 3.3, OS X 10.4.9 PowerPC using the beta-1.14.1.1 code:
configure: error: libexpat not found
make: *** [config.status] Error 1

Looks like the libexpat* in /tmp/expat/lib need to be copied somewhere but not sure where. I tried copying /tmp/expat/lib/* into /usr/local/lib which seems to get pass the missing libexpat error, but the comes up with error:

src/Makefile.am: required file `./depcomp' not found
make[1]: *** [Makefile.in] Error 1
make: *** [all-recursive] Error 1

Open for suggestion, I'm not a C++ person, but want to learn with SL Viewer --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 22:03, 7 April 2007 (PDT)

- After typing make, a Warning shows up but keeps compiling, not sure if causing the libexpat not found. PPC 10.4.9, Xcode 2.44.1 using the beta-1.14.1.1 code --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 11:45, 7 April 2007 (PDT)
$make
cd . && aclocal
cd . && automake --gnu Makefile
cd . && autoconf
/bin/sh ./config.status --recheck
running /bin/sh ./configure --disable-shared --prefix=/tmp/xmlrpc-epi --no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/Users/mokele/documents/second_life/Viewer_Code/lindenlib/xmlrpc-epi-0.51/missing: Unknown `--run' option
Try `/Users/mokele/documents/second_life/Viewer_Code/lindenlib/xmlrpc-epi-0.51/missing --help' for more information
configure: WARNING: `missing' script is too old or missing

== Curl ==

In the download of the SL libs, header files for Curl are included. Is this something that should is also required for a succesful build? Thanks. [[User:David Frantisek|David Frantisek]] 19:57, 8 January 2007 (PST)

Can't get CURL to compile, code below of what happens, gcc 3.3, OS X 10.4.9, PPC --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 23:56, 7 April 2007 (PDT)

checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** No rule to make target `clean'. Stop.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
checking whether to enable maintainer-specific portions of Makefiles... no
checking for sed... /usr/bin/sed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking curl version... 7.16.1
checking build system type... powerpc-apple-darwin8.9.0
checking host system type... powerpc-apple-darwin8.9.0
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** No rule to make target `clean'. Stop.
./configure
checking whether to enable maintainer-specific portions of Makefiles... no
checking for sed... /usr/bin/sed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking curl version... 7.16.1
checking build system type... powerpc-apple-darwin8.9.0
checking host system type... powerpc-apple-darwin8.9.0
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [all] Error 77
make: *** No rule to make target `install'.
cp: /Users/mokele/documents/second_life/viewer_code/lindenlib/curl/build-c-ares/lib/libcares.a: No such file or directory
cp: /Users/mokele/documents/second_life/viewer_code/lindenlib/curl/build-curl/lib/libcurl.a: No such file or directory
tar: libcares.a: Cannot stat: No such file or directory
tar: libllcurl.a: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors

== OpenJPEG ==

At least on my Macbook Pro, the latest (1.1) version of OpenJPEG would not compile, giving the error "make: *** No rule to make target `libopenjpeg/fix.o', needed by `libopenjpeg.a'. Stop.". Downloading the 1.0 version and following the instructions worked fine. [[User:Phineas Pegler|Phineas Pegler]] 22:48, 8 January 2007 (EST)
:I had the same experience, although I didn't try the 1.0 version - thanks for the suggestion :-) [[User:David Frantisek|David Frantisek]] 00:21, 12 January 2007 (PST)

- Can't get OpenJPEG to compile, get the error message:

make -f Makefile-i386.ppc libopenjpeg.a
gcc -isysroot /Developer/SDKs/MacOSX10.3.9.sdk -O3 -arch ppc -Ilibopenjpeg -c libopenjpeg/bio.c -o libopenjpeg/bio.o
gcc: cannot specify -o with -c or -S and multiple compilations
make: *** [libopenjpeg/bio.o] Error 1

gcc 3.3, Mac OS X 10.4.9 PPC --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 23:45, 7 April 2007 (PDT)

== Compiling/Running on OS X ==

I have the client successfully built and running on my Macbook Pro running 10.4.8 and XCode 2.2.1, using the linden library tarball. The only stumbling block is that it would not run using the "Development" build configuration, only under the "Deployment" config. Running under "Development" crashed on startup within Freetype, with a EXC_BAD_ACCESS. [[User:Phineas Pegler|Phineas Pegler]] 15:48, 11 January 2007 (EST)
:How does it run compared to the Linden Labs' release? [[User:David Frantisek|David Frantisek]] 00:22, 12 January 2007 (PST)
:: Even slower. I'll pop in some more memory and see if that helps. [[User:Phineas Pegler|Phineas Pegler]] 10:06, 12 January 2007 (EST)

== build the project w/ gcc 3.3 or 4.0? ==

In the section "Building the Viewer", it describes setting up and building, then changing your gcc back to 4.0. When I tried building with gcc set to 3.3, I got lots of errors about std::isfinite not defined (sorry I did not copy the exact error).

When I set gcc to 4.0 first, then built, I was able to build the client a-ok. I was thinking of reversing the two paragraphs (gcc 4.0 first, then build project) -- but I don't have any knowledge of the gcc, so figured I'd ask here.

none of any of the external libraries I could build with GCC 3.3, did some research and gcc 3.3 does not work correctly on intel macs [[User:Eelke Forder| Eelke Folmer]]

== Changes to Boost instructions? ==

I downloaded the Boost libraries, and noticed that the instructions for may need to be changed. Boost extracts to "<working directory>/boost_1_33_0" rather than "<working directory>/boost-1.33.0". Note underscores in place of hyphens and dots. As hinted by the instructions, I was able to build boost, but none of the files to be copied in the "Copy the Libraries" section appeared to have been built. Should this section of the instructions be updated? [[User:Simon Nolan|Simon Nolan]] 20:07, 2 April 2007 (PDT)

Aparently copying the header files is enough to get it running [[User:Eelke Forder | Eelke Folmer]] OS 10.4.9

I updated the section to reflect that the name uses underscores and not dash and periods. --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 04:56, 7 April 2007 (PDT)

Viewer Architecture

2007-04-08T11:21:15Z

Hunting Hare: /* User Guides */ Change lslwiki.com to lslwiki.net

{{OSWikiLearnBox}}

The Second Life client (also known as the "viewer") is a complex piece of software. It can be visualized as a streaming media client like RealPlayer, a game engine like Quake 3, or a web browser.

First you'll need to learn some terminology like "agent", "sim", and "region" in the [[glossary]].

== Learn by Example ==
* [[Adding a menu item]]
* [[Adding a dialog]]
* [[How movement works]]
* [[How the camera works]]
* [[How login works]]
* [[Hegemons Login Analysis]]
* [[How keyboard processing works]]
* [[How scripts work]]
* [[The lifetime of a session]]
* [[How preferences work]]

== Major Systems ==
* [[Message System]] - reliable and unreliable transport over UDP
* [[Image System]] - prioritizes and decodes JPEG2000 images into OpenGL textures
** [[Texture cache]] - used for reading and writing texture data to the local disk cache
* [[Viewer Object System]] - objects in scene for rendering and editing
* [[Rendering System]] - from viewer object to drawable to face to vertices to graphics card
* [[Culling]] - octree and occlusion based culling to speed rendering
* [[UI Widgets]] - cross platform buttons, scroll bars, etc.
* [[UI Floaters]] - dialogs and windows built from XML files
* [[Asset System]] - transport for animations, sounds, notecards, scripts, etc.
* [[Inventory]] - server-side storage of assets for each user
* [[Sound System]] - cross platform audio based on FMOD
* [[Movie System]] - QuickTime-based video on object surfaces
* [[VFS]] - cached data is held in two "virtual file systems" in large files on the client
* [[Selection Manager]] - holds extended information for selected objects and allows editing
* [[Avatar Appearance]] - appearance is constructed from a mesh, parameters to deform the mesh, and textures to describe clothing
* [[Web Browser]] - the integration of the viewer with the web.
* [[Avatar Profiles]]
* [[Groups]]
* [[L$ System]]
* [[Tools]] - anything that takes effect when you click your mouse on the world view.
* [[Error Logging System]] - command and control of debugging output

== Threads ==
The viewer is a single process with a few threads:
* Main thread -- The input/output main program function (including rendering).
* VFS thread -- Thread responsible for reading/writing to the local virtual file system.
* LFS thread -- Thread responsible for some reading/writing to the local native file system.
** Used by the {{OSWiki|Threaded_Image_Pipeline}} project
* Image thread -- Thread responsible for requesting and decoding image data
** Used by the {{OSWiki|Threaded_Image_Pipeline}} project
* Error Thread -- Thread responsible for catching exceptions, calling the (currently unused?) error handler, and retiring
* Worker Threads -- Threads designed to do cpu intensive background tasks
** These threads may be paused during rendering so as not to reduce performance (design in-progress)

== Program Flow ==
# Initialize - newview/viewer.cpp :: main()
# Loop - newview/viewer.cpp :: main_loop()
#* Gathers keyboard and mouse input
#* Pumps the TCP i/o
#* idle()
#* Render the frame
#* let filesystem and worker threads process
# Shutdown
One way to see what goes on in the main loop is to bring up the debug menus (Ctrl-Alt-D) then Client->Consoles->Fast Timers (or Ctrl-Shift-9) and expand the entries in the caption.

== Sources of Input ==
* The [[Message System]].
** Assets through the [[Asset System]], transmitted using the [[Transfer Manager]], and extracted from the [[VFS]].
** Files through [[Xfer Manager]].
* Files copied out of a [[VFS]] into local file store and read through c/c++/ll file API.
* XMLRPC calls such as [[Authentication Flow|login]] and [[Buying Land and Currency]].
* HTTP GET/POST to the [[Backbone]]. This is not yet in use.
* Streaming music and videos.
** Quicktime.
** FMOD.
* The web browser.

== User Guides ==

* [[Viewer coordinate frames]].
* Known [[Client_parameters]]
* Known Client Parameters on [http://lslwiki.net/lslwiki/wakka.php?wakka=newview&show_comments=1 LSLwiki.net]
* Known [[defines]]
* [[Godmode]] - what Lindens can do

Roadmap

2007-01-29T13:24:01Z

Hunting Hare: fix link to user

{{OSWikiLearnBox}}

'''January 8, 2007''' - This hardly constitutes a proper roadmap just yet, but here's the direction we're heading.

* '''Decrease coupling of viewer/server''' - If you work with our viewer enough, you'll notice that often you can't hook up to the main (Agni) grid. This is due to the tight coupling of viewers and servers, which will make it very difficult to keep the source release synced with the current viewer/server release. Fixing this issue correctly is where the work that {{User|Zero Linden}} described in his blog post "[http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/ A Big Change You'll Barely Notice]". In the next few months, this coupling will be reduced such that having a heterogeneous pool of viewers is just fine.
* '''Document what we're thinking about''' - yes, this is a copout. One thing on our roadmap is make a roadmap.
* '''Hold roundtables''' - We're hoping to start up [[:Category:Future Roundtables|roundtable meetings]] to help chart the direction. We've certainly got ideas of our own, but we want to get a sense of what others are thinking.
* '''Distribute binaries that correspond to source releases''' - Entered from [[Downloading_test_builds]] by [[User:Hunting_Hare|Hunting Hare]], not a Linden.

Running Multiple Viewers

2007-01-29T13:22:29Z

Hunting Hare: include relevant info for MacOSX, and remove "vital info missing" tag

For Windows:

# Make a new shortcut to the SL exe file.
# Then in that shortcut go to properties.
# Then in the properties find the Target box.
#* It will say something like "C:\Program Files\SecondLife\SecondLife.exe"
# Just after the last " in that box put this in. -multiple
#* So it reads like this "C:\Program Files\SecondLife\SecondLife.exe" -multiple

That lets you open as many as your computer can handle.

(You can only have one login at a time to an account. So you'll need a second account for the second SL client you have open. Etc. Max is 5 per household.)

On Mac OS X:
# you can specify command line options by selecting the "newview" executable, opening the "get info" dialog, and add them to the "Arguments to be passed on launch" on the "Arguments" tab.

[[Category:Text from In-world Notecards|Viewer, Running Multiple Instances]]

Roadmap

2007-01-29T13:09:50Z

Hunting Hare: copy relevant info from Downloading_Test_Builds page

BVH

2007-01-22T09:56:42Z

Hunting Hare: fix the link

A BVH file is a file in the BioVision Hierarchal data format, and is used to specify the changes (deltas) between frames in moving bodies.

http://www.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html

BVH

2007-01-22T09:55:50Z

Hunting Hare: Link to external description of file format

A BVH file is a file in the BioVision Hierarchal data format, and is used to specify the changes (deltas) between frames in moving bodies.

[[http://www.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html]]

Protocol

2007-01-22T09:52:08Z

Hunting Hare: /* Animation */ - make link

{{OSWikiLearnBox}}

In order to spot potential trouble spots, we want to have a pretty clear understanding of the UDP, TCP, and by-product communication between the client and the servers.

== The UDP Message System ==
* [[Message Layout]] -- Explanation of message format and the message template
* [[Packet Layout]] -- the layout of the UDP payload.
* [[Circuits]] -- Establishment and common operation of UDP circuits between two nodes
* [[Packet Accounting]] -- how the message system handles packet sequencing, reliability, suppression, throttling, etc.
* [[Common Messages]] -- messages that are handled by every Indra message system instance.
* [[Xfer Manager]] -- messages used by the <code>LLXFerManager</code> class.
* [[Transfer Manager]] -- messages used by the <code>LLTransferManger</code> class.

=== Communication with userserver ===
* [[Userserver Agent]] -- agent update information which alters userserver state.
* [[Userserver Relay]] -- messages relayed between the back-end systems and the viewer.

=== Communication with simulator ===
* [[Agent Messages]] -- agent movement, animation, appearance, etc.
* [[Inventory Messages]] -- agent inventory and asset management.
* [[Money Messages]] -- money queries and updates.
* [[Object Messages]] -- object and prim interaction.
* [[Parcel Messages]] -- parcel and land management and interaction.
* [[Region Messages]] -- interaction with the region, nearby regions, and movement between them.
* [[Communication Messages]] -- chat, instant messages, and lsl script interaction.
* [[Group Messages]] -- joining, management, and group related messages.
* [[Relationship Messages]] -- friends, granted rights, calling cards, and mute.
* [[Search Messages]] -- access to global search services.
* [[Avatar Appearance]] -- messages controlling avatar appearance

== XMLRPC Transactions ==
* [[Authentication Flow]] -- step-by-step diagram of login process
* [[Buying Land and Currency]] -- viewer side purchasing of land and currency.
* [[Capabilities]] -- authorization requests

== File Formats ==
=== Asset Files ===
* [[Textures]]
* [[Sounds]]
* [[Landmarks]]
* [[Notecards]]
* [[LSL Text]]
* [[LSL Bytecode]]
* [[Bodypart]]
* [[Animations]]
* [[Gestures]]

=== Media Files ===
==== Image format ====
* [http://en.wikipedia.org/wiki/Jpeg jpeg]
* [http://en.wikipedia.org/wiki/Jpeg_2000 JPEG2000]
* [http://en.wikipedia.org/wiki/Truevision_TGA tga (Truevision targa)]
* [http://en.wikipedia.org/wiki/Windows_bitmap bmp (Windows bitmap)]

==== Audio ====
* wav files
==== Animation ====
* [[BVH]] files for animations

==== Linden Files ====
* raw files for uploading sim land information
* LL DXT files

=== Miscellaneous Files ===
* [[Task Inventory]]
* [[Mute List]]

User:Hunting Hare

2007-01-17T11:58:15Z

Hunting Hare:

Notes to self:

Figure out the best way of handling [[trusted]] -- should it be a category instead of a standard list?

Figure out the best way of handling [[untrusted]] -- like [[trusted]], should it be a category?

[[Category:English speaking Residents]]

User:Hunting Hare

2007-01-17T11:57:35Z

Hunting Hare: Edit my category affiliation

Untrusted

2007-01-17T11:46:27Z

Hunting Hare: Fix EstablishTrustedCircuit to be CreateTrustedCircuit

An untrusted [[message]] may be sent across either a [[trusted]] or an untrusted [[circuit]].

Since the [[viewer]] may not establish a trusted circuit, it may only send untrusted messages. Since it is not possible for the [[viewer]] to authenticate a circuit (with the [[CreateTrustedCircuit]] message), it cannot upgrade any circuit to [[trusted]] status, and thus must drop all [[trusted]] messages.

==List of untrusted messages==

[*TODO [[User:Hunting Hare|Hunting Hare]] 03:46, 17 January 2007 (PST)]

Untrusted

2007-01-17T11:45:44Z

Hunting Hare: Initial Entry

An untrusted [[message]] may be sent across either a [[trusted]] or an untrusted [[circuit]].

Since the [[viewer]] may not establish a trusted circuit, it may only send untrusted messages. Since it is not possible for the [[viewer]] to authenticate a circuit (with the [[EstablishTrustedCircuit]] message), it cannot upgrade any circuit to [[trusted]] status, and thus must drop all [[trusted]] messages.

==List of untrusted messages==

[*TODO [[User:Hunting Hare|Hunting Hare]] 03:45, 17 January 2007 (PST)]

Trusted

2007-01-17T11:29:59Z

Hunting Hare: Initial entry

A trusted message is a message which will only be accepted from a [[circuit]] which has been marked as trusted, through the use of the [[DenyTrustedCircuit]] and [[CreateTrustedCircuit]] handshakes.

Due to the fact that ONLY [[simulators]] and [[utility servers]] can perform the [[CreateTrustedCircuit]] handshake successfully, any attempt by a [[viewer]] to use these messages will automatically fail.

== List of Trusted Messages ==

[*TODO [[User:Hunting Hare|Hunting Hare]] 03:29, 17 January 2007 (PST)]

Simulators

2007-01-17T11:28:32Z

Hunting Hare: Redirection to the singular form

#REDIRECT [[simulator]]

User:Hunting Hare

2007-01-17T11:23:01Z

Hunting Hare: Note to self

Simulator

2007-01-17T11:19:23Z

Hunting Hare: Redirection to the glossary

#REDIRECT [[Glossary#Simulator]]

Viewer

2007-01-17T11:18:06Z

Hunting Hare: Redirection to the glossary

#REDIRECT [[Glossary#Viewer]]

UDP

2007-01-17T11:13:44Z

Hunting Hare: Initial Entry

Usergram Data Protocol, an unreliable and unstreamed transmission packet format over TCP/IP networks. To describe what UDP is, it's easier to explain in terms of what it isn't -- and that's best explained by describing the guarantee that its counterpart, Transmission Control Protocol, provides. In TCP, each packet of data is given the following guarantee: if it arrives, it will reliably arrive in order (no data will be lost from the stream before it, and no data from the stream which was sent after it will be delivered to the application before it).

In UDP, no guarantee that it will be delivered at all, in any given order, or in any given timeframe is provided by the network layer. This may sound like a negative, and for many purposes it is -- but it also uses a little less than one half of the packets used by TCP. This lower number of packets makes it the only useful choice in situations which are time-sensitive, including streaming audio and video. This lower number of packets also makes it suitable for situations where not every packet must arrive perfectly intact in order, including DNS (name to address resolution on the Internet) and Second Life.

For more information on TCP and UDP, please see their respective definition documents. (Note that these protocols use the services provided by the IP layer underneath them, be it IPv4 or IPv6.)

[ftp://ftp.rfc-editor.org/in-notes/rfc768.txt User Datagram Protocol]

[ftp://ftp.rfc-editor.org/in-notes/rfc793.txt Transmission Control Protocol]

Compiling the viewer (Mac OS X)

2007-01-15T09:52:51Z

Hunting Hare: explanation of why fmodapi isn't included with the libraries package

{{CompileNav}}

The following are instructions for building the Second Life viewer on Mac OS X. For other platforms, see [[Compiling the viewer]]

= Development Environment =
We use XCode 2.4.1 for building on Macintosh computers. For simplicity, we suggest installing everything from the mpkg.

You will need to install the proprietary libraries as well as all of the other third party libraries below. For convenience, we package up the libraries we are allowed to distribute so you can either download that package and unpack it into your development working directory or install all of the libraries from scratch.

= Installing Proprietary Libraries =

We do not distribute these libraries, so you will need to fetch and install these even if you download the libraries packages. (This is due to licensing restrictions. Don't ask, we already did, and can't get permission. So you do have to get them yourself.)

== Fmod ==
* Download & extract [http://www.fmod.org/ifmoddownload.html fmod 3.75 programmers api for macintosh].
* (You do *not* want the latest version, instead scroll down to v3.75)
* Copy the extracted files. Note the name change for the x86 library.
<pre>
$ cp -p fmodapi375mac/api/inc/*.h linden/libraries/include
$ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc-darwin/lib_debug
$ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc-darwin/lib_release
$ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386-darwin/lib_debug/libfmod.a
$ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386-darwin/lib_release/libfmod.a
</pre>

= Installing Libraries =
We supply a package of the required libraries and binaries on the [[compiling the viewer]] page.

From the directory where you downloaded the tarballs:

tar xvfz sl-source.tar.gz
tar xvfz sl-libraries.tar.gz

Your filenames may vary. If you open them with the double click file extract, remember that dragging folders on top of each other will overwrite the original contents, not merge them as in windows.

= Installing Libraries From Scratch =
We recommend creating a separate third party library directory named 'lindenlib' on the same level as the 'linden' tree in your directory structure. Download, unpack, and build from there and copy the files specified to their final location.

Most of the libs built here are architecture specific, so these instructions will refer to $PLATFORM to denote that. You can set an environment variable to make it so copy & paste from these instructions will work:
<pre>
$ PLATFORM=`uname -p`-darwin
</pre>
Building the Universal target requires that you have built both the i386 and ppc libraries. (Please see [http://developer.apple.com/technotes/tn2005/tn2137.html] for more background information.)

Using gcc 4.0 on a ppc box when building many of these libraries will insert an undefined reference to _fprintf$LBDLStub which then fails to link later. Until we have a better solution to this issue, you will need to use an earlier version of gcc. Some of the instructions below will include a call to gcc_select which is only necessary if you are building on a ppc box.

== Boost ==
Download & extract [http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041 Boost] source.
The viewer does not link to the boost libraries, so much of this is not necessary. You can simply copy the header files if you have problems getting the boost package to build.
=== Copy the Headers ===
<pre>
$ cp -r lindenlib/boost-1.33.0/boost linden/libraries/include/boost
</pre>
=== Build Boost.Jam ===
<pre>
$ cd boost-1.33.0/tools/build/jam_src
$ ./build.sh
$ if [ $PLATFORM = "i386-darwin" ] then PLATDIR=bin.macosxx86; else PLATDIR=bin.macosxppc; fi
$ cp $PLATDIR/bjam ../../..
$ unset PLATDIR
</pre>
=== Build Boost ===
<pre>
$ cd boost-1.33.0/libs
$ export PYTHON_ROOT=/System/Library/Frameworks/Python.framework/Versions/2.3/
$ export PYTHON_VERSION=2.3
$ ./bjam stage
</pre>
=== Copy the Libraries ===
<pre>
$ sudo gcc_select 4.0
$ cd boost-1.33.0
$ export PLATFORM=`uname -p`-darwin
$ cp src/stage/lib/libboost_python-gcc.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_python-gcc-d.a \
libraries/$PLATFORM/lib_debug/libboost_python-gcc.a
$ cp src/stage/lib/libboost_python-gcc-mt.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_python-gcc-mt-d.a \
libraries/$PLATFORM/lib_debug/libboost_python-gcc-mt.a
$ cp src/stage/lib/libboost_regex-gcc.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_regex-gcc-d.a \
libraries/$PLATFORM/lib_debug/libboost_regex-gcc.a
$ cp src/stage/lib/libboost_regex-gcc-mt.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_regex-gcc-mt-d.a \
libraries/$PLATFORM/lib_debug/libboost_regex-gcc-mt.a
</pre>

== Apache Portable Runtime ==
* Download & extract [http://apr.apache.org/download.cgi apr and apr-util].
* Build and install the headers and lib files using a terminal.
<pre>
$ sudo gcc_select 3.3
$ cd lindenlib/apr-1.2.8
$ ./configure --disable-shared --disable-lfs --prefix=/tmp/apr
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/apr/include/apr-1 linden/libraries/$PLATFORM/include
$ cp /tmp/apr/lib/libapr-1.a linden/libraries/$PLATFORM/lib_release
$ cp /tmp/apr/lib/libapr-1.a linden/libraries/$PLATFORM/lib_debug

$ cd lindenlib/apr-util-1.2.8
$ ./configure --disable-shared --disable-lfs --with-apr=/tmp/apr --prefix=/tmp/apr-util
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/apr-util/include/apr-1 linden/libraries/$PLATFORM/include
$ cp /tmp/apr-util/lib/*.a linden/libraries/$PLATFORM/lib_release
$ cp /tmp/apr-util/lib/*.a linden/libraries/$PLATFORM/lib_debug
$ sudo gcc_select 4.0
</pre>

== zlib ==
* Download and extract [http://www.zlib.net/ zlib].
* Build and install it.
<pre>
$ sudo gcc_select 3.3
$ cd zlib-1.2.3
$ ./configure --prefix=/tmp/zlib
$ make
$ make install
$ cd ../..
$ cp -Rp /tmp/zlib/include linden/libraries/include/zlib
$ cp -p /tmp/zlib/lib/libz.a linden/libraries/$PLATFORM/lib_debug/libllz.a
$ cp -p /tmp/zlib/lib/libz.a linden/libraries/$PLATFORM/lib_release/libllz.a
</pre>
* Note that the library has a different name in the libraries directory.

== Expat ==
* Download an extract the 1.95.8 version of [http://sourceforge.net/projects/expat/ expat].
* Build and install the library
<pre>
$ sudo gcc_select 3.3
$ cd expat-1.95.8
$ ./configure --prefix=/tmp/expat
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/expat/include linden/libraries/include/expat
$ cp -p /tmp/expat/lib/libexpat.a linden/libraries/$PLATFORM/lib_release
$ cp -p /tmp/expat/lib/libexpat.a linden/libraries/$PLATFORM/lib_debug
</pre>

== XMLRPC-epi ==
* Download a source package for [http://xmlrpc-epi.sourceforge.net/ xmlrpc-epi].
* Apply patch 1 and 2 from the instructions in [[patch xmlrpc-epi]].
* Configure the project:
<pre>
$ sudo gcc_select 3.3
$ cd xmlrpc-epi-0.51
$ ./configure --disable-shared --prefix=/tmp/xmlrpc-epi
</pre>
* Apply patch 3 from the instructions in [[patch xmlrpc-epi]].
* Finish the removal of expat, build, and install
<pre>
$ rm -rf expat
$ mkdir expat
$ cp /tmp/expat/include/* expat
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/xmlrpc-epi/include linden/libraries/include/xmlrpc-epi
$ cp -p /tmp/xmlrpc-epi/lib/libxmlrpc.a linden/libraries/$PLATFORM/lib_release
$ cp -p /tmp/xmlrpc-epi/lib/libxmlrpc.a linden/libraries/$PLATFORM/lib_debug
</pre>

== JPEGlib ==
* Download & extract [http://www.ijg.org/ jpeglib]. You will minimally need jpegsrc.v6b.tar.gz.
* Build and install the library:
<pre>
$ sudo gcc_select 3.3
$ cd jpeg-6b
$ ./configure
$ make
$ cd ../..
$ mkdir linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jconfig.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jerror.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jinclude.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jmorecfg.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jpeglib.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/libjpeg.a linden/libraries/$PLATFORM/lib_debug/liblljpeg.a
$ cp lindenlib/jpeg-6b/libjpeg.a linden/libraries/$PLATFORM/lib_release/liblljpeg.a
</pre>
* Note that the library has a different name in the libraries directory.
* If you plan to use the header file from windows, you will need to [[patch jpeglib]] using any terminal.

== OpenJPEG ==
* Download and extract version 1.0 [http://www.openjpeg.org/index.php?menu=download openjpeg] source.
* Copy the [[make openjpeg|linden openjpeg makefiles]] into the openjpeg source top level directory. We do this to maintain 10.3.9 compatibility.
* Build and install the library
<pre>
$ sudo gcc_select 3.3
$ mkdir ../../linden/libraries/include/openjpeg
$ cp -p libopenjpeg/openjpeg.h ../../linden/libraries/include/openjpeg
$ make -f Makefile-i386.ppc libopenjpeg.a
$ cp libopenjpeg.a ../../linden/libraries/ppc-darwin/lib_debug
$ cp libopenjpeg.a ../../linden/libraries/ppc-darwin/lib_release
$ make -f Makefile-i386.ppc clean
$ make -f Makefile-i386.osx libopenjpeg.a
$ cp libopenjpeg.a ../../linden/libraries/i386-darwin/lib_debug
$ cp libopenjpeg.a ../../linden/libraries/i386-darwin/lib_release
</pre>

== Freetype ==
* Download and extract [http://freetype.sourceforge.net/download.html#stable FreeType].
* Build and install the FreeType library:
<pre>
$ sudo gcc_select 3.3
$ cd freetype-2.2.1
$ ./configure --prefix=/tmp/freetype
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/freetype/include/freetype2/freetype linden/libraries/include
$ cp -p /tmp/freetype/include/freetype2/ft2build.h linden/libraries/include
$ cp -p /tmp/freetype/lib/libfreetype.a linden/libraries/$PLATFORM/lib_release
$ cp -p /tmp/freetype/lib/libfreetype.a linden/libraries/$PLATFORM/lib_debug
</pre>

== Vorbis & Ogg ==
* Download & extract [http://www.xiph.org/downloads/ libvorbis].
* Download & extract [http://www.xiph.org/downloads/ libogg].
* Build & copy libogg first:
<pre>
$ sudo gcc_select 3.3
$ cd libogg-1.1.3
$ ./configure --prefix=/tmp/ogg
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/ogg/include/ogg linden/libraries/include
$ cp -p /tmp/ogg/lib/libogg.a linden/libraries/$PLATFORM/lib_debug
$ cp -p /tmp/ogg/lib/libogg.a linden/libraries/$PLATFORM/lib_release
</pre>
* Build & copy libvorbis:
<pre>
$ sudo gcc_select 3.3
$ cd libvorbis-1.1.2
$ ./configure --prefix=/tmp/vorbis --with-ogg=/tmp/ogg
$ make
$ make install
$ ../..
$ cp -pR /tmp/vorbis/include/vorbis linden/libraries/include
$ cp -p /tmp/vorbis/lib/libvorbis*.a linden/libraries/$PLATFORM/lib_debug
$ cp -p /tmp/vorbis/lib/libvorbis*.a linden/libraries/$PLATFORM/lib_release
</pre>

== TUT ==
* Download [http://tut-framework.sourceforge.net/download/ tut] into lindenlib
* Move it into a sub-directory, extract, and copy the headers
<pre>
$ mkdir tut
$ mv TUT-2006-11-04.tar.gz tut
$ cd tut
$ tar xvzf TUT-2006-11-04.tar.gz
$ cd ../..
$ mkdir linden/libraries/include/tut
$ cp -p lindenlib/tut/tut.h lindenlib/tut/tut_reporter.h lindenlib/tut/tut_restartable.h linden/libraries/include/tut
</pre>

== Mozilla ==
*FIX: It's really hard to build the mozilla libs. Instructions coming.

= Building the Viewer =
Launch XCode, open the project file 'linden/indra/newview/macview.xcodeproj', set 'newview' as the active target, select an active build configuration, and build the project.

If you had to change gcc versions for a ppc build, restore gcc back to 4.0.
<pre>
$ sudo gcc_select 4.0
</pre>

== Build Configurations ==
* Development: This configuration is more suitable for debugging. The build process will create the SecondLife application targeted for your host architecture.
* Deployment: This configuration is faster than the development version at the cost of some ability to debug. The build process will create the SecondLife application targeted for your host architecture.
* Universal: This configuration is the same as the Deployment target except that all supported architectures - ppc and i386 - are built.

= Building the Unit Tests =
From XCode, open the project 'linden/indra/test/MacTester.xcodeproj', set 'MacTester' as the active target, and build.

Talk:Compiling the viewer (Mac OS X)

2007-01-15T09:36:52Z

Hunting Hare: Requested information to help track down environment-specific issues

==PLEASE NOTE==

When you report any problem, PLEASE post your OS version and version of Xcode. This will help identify the environments that have issues, and allow the creation of workarounds specific to those environments. Thank you! [[User:Hunting Hare|Hunting Hare]] 01:36, 15 January 2007 (PST)

==Mozilla==

I'm a bit confused about the Mozilla lib dependency--perhaps if someone knew what was actually required to be compiled (even if it would be somewhat difficult) we could at least try. :-) Thanks. [[User:David Frantisek|David Frantisek]] 19:55, 8 January 2007 (PST)

==Problems with directions==

It seems like there are a couple places here where problems are created because of the use of "../.." I'm not all that familiar with use of the terminal, but I think this puts you in your home directory, which is okay as long as that's the top-level of your project, but not if the top-level is ~/Desktop or somewhere else entirely. [[User:David Frantisek|David Frantisek]] 19:55, 8 January 2007 (PST)

''../.. refers to the parent of the parent folder -- from /Users/yourusername/ , ../.. would refer to the root directory that contains the Users folder. Remember, Mac OS X has the technological underpinning of BSD UNIX. If you're not familiar with the use of the Terminal, then you will likely find a book on using UNIX very helpful. For reference, the single character ~ refers to your home directory but only if it's used as the first element of a path specification -- ~/Desktop refers to your Desktop folder. ~username/ refers to the home directory of username. [[User:Hunting Hare|Hunting Hare]] 01:36, 15 January 2007 (PST)''

== Curl ==

In the download of the SL libs, header files for Curl are included. Is this something that should is also required for a succesful build? Thanks. [[User:David Frantisek|David Frantisek]] 19:57, 8 January 2007 (PST)

== OpenJPEG ==

At least on my Macbook Pro, the latest (1.1) version of OpenJPEG would not compile, giving the error "make: *** No rule to make target `libopenjpeg/fix.o', needed by `libopenjpeg.a'. Stop.". Downloading the 1.0 version and following the instructions worked fine. [[User:Phineas Pegler|Phineas Pegler]] 22:48, 8 January 2007 (EST)
:I had the same experience, although I didn't try the 1.0 version - thanks for the suggestion :-) [[User:David Frantisek|David Frantisek]] 00:21, 12 January 2007 (PST)

== Compiling/Running on OS X ==

I have the client successfully built and running on my Macbook Pro running 10.4.8 and XCode 2.2.1, using the linden library tarball. The only stumbling block is that it would not run using the "Development" build configuration, only under the "Deployment" config. Running under "Development" crashed on startup within Freetype, with a EXC_BAD_ACCESS. [[User:Phineas Pegler|Phineas Pegler]] 15:48, 11 January 2007 (EST)
:How does it run compared to the Linden Labs' release? [[User:David Frantisek|David Frantisek]] 00:22, 12 January 2007 (PST)
:: Even slower. I'll pop in some more memory and see if that helps. [[User:Phineas Pegler|Phineas Pegler]] 10:06, 12 January 2007 (EST)

Talk:Compiling the viewer (Mac OS X)

2007-01-15T09:29:27Z

Hunting Hare: /* Problems with directions */

==Mozilla==

I'm a bit confused about the Mozilla lib dependency--perhaps if someone knew what was actually required to be compiled (even if it would be somewhat difficult) we could at least try. :-) Thanks. [[User:David Frantisek|David Frantisek]] 19:55, 8 January 2007 (PST)

==Problems with directions==

It seems like there are a couple places here where problems are created because of the use of "../.." I'm not all that familiar with use of the terminal, but I think this puts you in your home directory, which is okay as long as that's the top-level of your project, but not if the top-level is ~/Desktop or somewhere else entirely. [[User:David Frantisek|David Frantisek]] 19:55, 8 January 2007 (PST)

''../.. refers to the parent of the parent folder -- from /Users/yourusername/ , ../.. would refer to the root directory that contains the Users folder. Remember, Mac OS X has the technological underpinning of BSD UNIX. If you're not familiar with the use of the Terminal, then you will likely find a book on using UNIX very helpful. For reference, the single character ~ refers to your home directory but only if it's used as the first element of a path specification -- ~/Desktop refers to your Desktop folder. ~username/ refers to the home directory of username. [[User:Hunting Hare]] 01:30, 15 January 2007 (PST)''

== Curl ==

In the download of the SL libs, header files for Curl are included. Is this something that should is also required for a succesful build? Thanks. [[User:David Frantisek|David Frantisek]] 19:57, 8 January 2007 (PST)

== OpenJPEG ==

At least on my Macbook Pro, the latest (1.1) version of OpenJPEG would not compile, giving the error "make: *** No rule to make target `libopenjpeg/fix.o', needed by `libopenjpeg.a'. Stop.". Downloading the 1.0 version and following the instructions worked fine. [[User:Phineas Pegler|Phineas Pegler]] 22:48, 8 January 2007 (EST)
:I had the same experience, although I didn't try the 1.0 version - thanks for the suggestion :-) [[User:David Frantisek|David Frantisek]] 00:21, 12 January 2007 (PST)

== Compiling/Running on OS X ==

I have the client successfully built and running on my Macbook Pro running 10.4.8 and XCode 2.2.1, using the linden library tarball. The only stumbling block is that it would not run using the "Development" build configuration, only under the "Deployment" config. Running under "Development" crashed on startup within Freetype, with a EXC_BAD_ACCESS. [[User:Phineas Pegler|Phineas Pegler]] 15:48, 11 January 2007 (EST)
:How does it run compared to the Linden Labs' release? [[User:David Frantisek|David Frantisek]] 00:22, 12 January 2007 (PST)
:: Even slower. I'll pop in some more memory and see if that helps. [[User:Phineas Pegler|Phineas Pegler]] 10:06, 12 January 2007 (EST)

Compiling the viewer (Mac OS X)

2007-01-14T01:51:30Z

Hunting Hare: clean up some minor gotchas, add reference to ADC for Universal

{{CompileNav}}

The following are instructions for building the Second Life viewer on Mac OS X. For other platforms, see [[Compiling the viewer]]

= Development Environment =
We use XCode 2.4.1 for building on Macintosh computers. For simplicity, we suggest installing everything from the mpkg.

You will need to install the proprietary libraries as well as all of the other third party libraries below. For convenience, we package up the libraries we are allowed to distribute so you can either download that package and unpack it into your development working directory or install all of the libraries from scratch.

= Installing Proprietary Libraries =

We do not distribute these libraries, so you will need to fetch and install these even if you download the libraries packages.

== Fmod ==
* Download & extract [http://www.fmod.org/ifmoddownload.html fmod 3.75 programmers api for macintosh].
* (You do *not* want the latest version, instead scroll down to v3.75)
* Copy the extracted files. Note the name change for the x86 library.
<pre>
$ cp -p fmodapi375mac/api/inc/*.h linden/libraries/include
$ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc-darwin/lib_debug
$ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc-darwin/lib_release
$ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386-darwin/lib_debug/libfmod.a
$ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386-darwin/lib_release/libfmod.a
</pre>

= Installing Libraries =
We supply a package of the required libraries and binaries on the [[compiling the viewer]] page.

From the directory where you downloaded the tarballs:

tar xvfz sl-source.tar.gz
tar xvfz sl-libraries.tar.gz

Your filenames may vary. If you open them with the double click file extract, remember that dragging folders on top of each other will overwrite the original contents, not merge them as in windows.

= Installing Libraries From Scratch =
We recommend creating a separate third party library directory named 'lindenlib' on the same level as the 'linden' tree in your directory structure. Download, unpack, and build from there and copy the files specified to their final location.

Most of the libs built here are architecture specific, so these instructions will refer to $PLATFORM to denote that. You can set an environment variable to make it so copy & paste from these instructions will work:
<pre>
$ PLATFORM=`uname -p`-darwin
</pre>
Building the Universal target requires that you have built both the i386 and ppc libraries. (Please see [http://developer.apple.com/technotes/tn2005/tn2137.html] for more background information.)

Using gcc 4.0 on a ppc box when building many of these libraries will insert an undefined reference to _fprintf$LBDLStub which then fails to link later. Until we have a better solution to this issue, you will need to use an earlier version of gcc. Some of the instructions below will include a call to gcc_select which is only necessary if you are building on a ppc box.

== Boost ==
Download & extract [http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041 Boost] source.
The viewer does not link to the boost libraries, so much of this is not necessary. You can simply copy the header files if you have problems getting the boost package to build.
=== Copy the Headers ===
<pre>
$ cp -r lindenlib/boost-1.33.0/boost linden/libraries/include/boost
</pre>
=== Build Boost.Jam ===
<pre>
$ cd boost-1.33.0/tools/build/jam_src
$ ./build.sh
$ if [ $PLATFORM = "i386-darwin" ] then PLATDIR=bin.macosxx86; else PLATDIR=bin.macosxppc; fi
$ cp $PLATDIR/bjam ../../..
$ unset PLATDIR
</pre>
=== Build Boost ===
<pre>
$ cd boost-1.33.0/libs
$ export PYTHON_ROOT=/System/Library/Frameworks/Python.framework/Versions/2.3/
$ export PYTHON_VERSION=2.3
$ ./bjam stage
</pre>
=== Copy the Libraries ===
<pre>
$ sudo gcc_select 4.0
$ cd boost-1.33.0
$ export PLATFORM=`uname -p`-darwin
$ cp src/stage/lib/libboost_python-gcc.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_python-gcc-d.a \
libraries/$PLATFORM/lib_debug/libboost_python-gcc.a
$ cp src/stage/lib/libboost_python-gcc-mt.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_python-gcc-mt-d.a \
libraries/$PLATFORM/lib_debug/libboost_python-gcc-mt.a
$ cp src/stage/lib/libboost_regex-gcc.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_regex-gcc-d.a \
libraries/$PLATFORM/lib_debug/libboost_regex-gcc.a
$ cp src/stage/lib/libboost_regex-gcc-mt.a \
libraries/$PLATFORM/lib_release
$ cp src/stage/lib/libboost_regex-gcc-mt-d.a \
libraries/$PLATFORM/lib_debug/libboost_regex-gcc-mt.a
</pre>

== Apache Portable Runtime ==
* Download & extract [http://apr.apache.org/download.cgi apr and apr-util].
* Build and install the headers and lib files using a terminal.
<pre>
$ sudo gcc_select 3.3
$ cd lindenlib/apr-1.2.8
$ ./configure --disable-shared --disable-lfs --prefix=/tmp/apr
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/apr/include/apr-1 linden/libraries/$PLATFORM/include
$ cp /tmp/apr/lib/libapr-1.a linden/libraries/$PLATFORM/lib_release
$ cp /tmp/apr/lib/libapr-1.a linden/libraries/$PLATFORM/lib_debug

$ cd lindenlib/apr-util-1.2.8
$ ./configure --disable-shared --disable-lfs --with-apr=/tmp/apr --prefix=/tmp/apr-util
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/apr-util/include/apr-1 linden/libraries/$PLATFORM/include
$ cp /tmp/apr-util/lib/*.a linden/libraries/$PLATFORM/lib_release
$ cp /tmp/apr-util/lib/*.a linden/libraries/$PLATFORM/lib_debug
$ sudo gcc_select 4.0
</pre>

== zlib ==
* Download and extract [http://www.zlib.net/ zlib].
* Build and install it.
<pre>
$ sudo gcc_select 3.3
$ cd zlib-1.2.3
$ ./configure --prefix=/tmp/zlib
$ make
$ make install
$ cd ../..
$ cp -Rp /tmp/zlib/include linden/libraries/include/zlib
$ cp -p /tmp/zlib/lib/libz.a linden/libraries/$PLATFORM/lib_debug/libllz.a
$ cp -p /tmp/zlib/lib/libz.a linden/libraries/$PLATFORM/lib_release/libllz.a
</pre>
* Note that the library has a different name in the libraries directory.

== Expat ==
* Download an extract the 1.95.8 version of [http://sourceforge.net/projects/expat/ expat].
* Build and install the library
<pre>
$ sudo gcc_select 3.3
$ cd expat-1.95.8
$ ./configure --prefix=/tmp/expat
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/expat/include linden/libraries/include/expat
$ cp -p /tmp/expat/lib/libexpat.a linden/libraries/$PLATFORM/lib_release
$ cp -p /tmp/expat/lib/libexpat.a linden/libraries/$PLATFORM/lib_debug
</pre>

== XMLRPC-epi ==
* Download a source package for [http://xmlrpc-epi.sourceforge.net/ xmlrpc-epi].
* Apply patch 1 and 2 from the instructions in [[patch xmlrpc-epi]].
* Configure the project:
<pre>
$ sudo gcc_select 3.3
$ cd xmlrpc-epi-0.51
$ ./configure --disable-shared --prefix=/tmp/xmlrpc-epi
</pre>
* Apply patch 3 from the instructions in [[patch xmlrpc-epi]].
* Finish the removal of expat, build, and install
<pre>
$ rm -rf expat
$ mkdir expat
$ cp /tmp/expat/include/* expat
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/xmlrpc-epi/include linden/libraries/include/xmlrpc-epi
$ cp -p /tmp/xmlrpc-epi/lib/libxmlrpc.a linden/libraries/$PLATFORM/lib_release
$ cp -p /tmp/xmlrpc-epi/lib/libxmlrpc.a linden/libraries/$PLATFORM/lib_debug
</pre>

== JPEGlib ==
* Download & extract [http://www.ijg.org/ jpeglib]. You will minimally need jpegsrc.v6b.tar.gz.
* Build and install the library:
<pre>
$ sudo gcc_select 3.3
$ cd jpeg-6b
$ ./configure
$ make
$ cd ../..
$ mkdir linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jconfig.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jerror.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jinclude.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jmorecfg.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/jpeglib.h linden/libraries/include/jpeglib
$ cp lindenlib/jpeg-6b/libjpeg.a linden/libraries/$PLATFORM/lib_debug/liblljpeg.a
$ cp lindenlib/jpeg-6b/libjpeg.a linden/libraries/$PLATFORM/lib_release/liblljpeg.a
</pre>
* Note that the library has a different name in the libraries directory.
* If you plan to use the header file from windows, you will need to [[patch jpeglib]] using any terminal.

== OpenJPEG ==
* Download and extract version 1.0 [http://www.openjpeg.org/index.php?menu=download openjpeg] source.
* Copy the [[make openjpeg|linden openjpeg makefiles]] into the openjpeg source top level directory. We do this to maintain 10.3.9 compatibility.
* Build and install the library
<pre>
$ sudo gcc_select 3.3
$ mkdir ../../linden/libraries/include/openjpeg
$ cp -p libopenjpeg/openjpeg.h ../../linden/libraries/include/openjpeg
$ make -f Makefile-i386.ppc libopenjpeg.a
$ cp libopenjpeg.a ../../linden/libraries/ppc-darwin/lib_debug
$ cp libopenjpeg.a ../../linden/libraries/ppc-darwin/lib_release
$ make -f Makefile-i386.ppc clean
$ make -f Makefile-i386.osx libopenjpeg.a
$ cp libopenjpeg.a ../../linden/libraries/i386-darwin/lib_debug
$ cp libopenjpeg.a ../../linden/libraries/i386-darwin/lib_release
</pre>

== Freetype ==
* Download and extract [http://freetype.sourceforge.net/download.html#stable FreeType].
* Build and install the FreeType library:
<pre>
$ sudo gcc_select 3.3
$ cd freetype-2.2.1
$ ./configure --prefix=/tmp/freetype
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/freetype/include/freetype2/freetype linden/libraries/include
$ cp -p /tmp/freetype/include/freetype2/ft2build.h linden/libraries/include
$ cp -p /tmp/freetype/lib/libfreetype.a linden/libraries/$PLATFORM/lib_release
$ cp -p /tmp/freetype/lib/libfreetype.a linden/libraries/$PLATFORM/lib_debug
</pre>

== Vorbis & Ogg ==
* Download & extract [http://www.xiph.org/downloads/ libvorbis].
* Download & extract [http://www.xiph.org/downloads/ libogg].
* Build & copy libogg first:
<pre>
$ sudo gcc_select 3.3
$ cd libogg-1.1.3
$ ./configure --prefix=/tmp/ogg
$ make
$ make install
$ cd ../..
$ cp -pR /tmp/ogg/include/ogg linden/libraries/include
$ cp -p /tmp/ogg/lib/libogg.a linden/libraries/$PLATFORM/lib_debug
$ cp -p /tmp/ogg/lib/libogg.a linden/libraries/$PLATFORM/lib_release
</pre>
* Build & copy libvorbis:
<pre>
$ sudo gcc_select 3.3
$ cd libvorbis-1.1.2
$ ./configure --prefix=/tmp/vorbis --with-ogg=/tmp/ogg
$ make
$ make install
$ ../..
$ cp -pR /tmp/vorbis/include/vorbis linden/libraries/include
$ cp -p /tmp/vorbis/lib/libvorbis*.a linden/libraries/$PLATFORM/lib_debug
$ cp -p /tmp/vorbis/lib/libvorbis*.a linden/libraries/$PLATFORM/lib_release
</pre>

== TUT ==
* Download [http://tut-framework.sourceforge.net/download/ tut] into lindenlib
* Move it into a sub-directory, extract, and copy the headers
<pre>
$ mkdir tut
$ mv TUT-2006-11-04.tar.gz tut
$ cd tut
$ tar xvzf TUT-2006-11-04.tar.gz
$ cd ../..
$ mkdir linden/libraries/include/tut
$ cp -p lindenlib/tut/tut.h lindenlib/tut/tut_reporter.h lindenlib/tut/tut_restartable.h linden/libraries/include/tut
</pre>

== Mozilla ==
*FIX: It's really hard to build the mozilla libs. Instructions coming.

= Building the Viewer =
Launch XCode, open the project file 'linden/indra/newview/macview.xcodeproj', set 'newview' as the active target, select an active build configuration, and build the project.

If you had to change gcc versions for a ppc build, restore gcc back to 4.0.
<pre>
$ sudo gcc_select 4.0
</pre>

== Build Configurations ==
* Development: This configuration is more suitable for debugging. The build process will create the SecondLife application targeted for your host architecture.
* Deployment: This configuration is faster than the development version at the cost of some ability to debug. The build process will create the SecondLife application targeted for your host architecture.
* Universal: This configuration is the same as the Deployment target except that all supported architectures - ppc and i386 - are built.

= Building the Unit Tests =
From XCode, open the project 'linden/indra/test/MacTester.xcodeproj', set 'MacTester' as the active target, and build.