Second Life Wiki - User contributions [en]

Openjpeg improvements

2007-03-20T02:20:54Z

SpacedOut Frye: VWR-123 is now in the source tree

=Introduction=

There are two main directions to improve [http://www.openjpeg.org OpenJPEG].
<ul>
<li>Optimize the entropy coder (T1)</li>
<li>Optimize the wavelet transform (DWT)</li>
</ul>

Depending on the image characteristics, the complexity is distributed between these two blocks, as illustrated in the analysis below.

Says bushing:
<pre>
Analysis on OSX/PPC showed:

- 27.1% dwt_decode_1_real (OpenJPEG)
- 22.9% tcd_decode_tile (OpenJPEG)
- 5.6% t1_dec_sigpass_step (OpenJPEG)
- 5.4% t1_decode_cblks (OpenJPEG)
- 5.4% t1_dec_refpass_step (OpenJPEG)
- 4.7% mqc_decode (OpenJPEG)

tcd_decode_tile is really just a call to dwt_decode_real, so half of the
time is spent in dwt_decode_real and dwt_decode_1_real.

OpenJpeg: 1 min 25 sec
GeoJasPer: 1 min 34 sec
Kakadu: 19 sec (!)

</pre>

== Related issues/patches in JIRA ==

* [https://jira.secondlife.com/browse/VWR-123 VWR-123: OpenJPEG meta decode, Second Life patches] -- included as of FL-1.13.3.59315

= T1 Optimization=
Stefan Westerfeld has started to [http://space.twc.de/~stefan/quickOpenJPEG/ optimize the T1].

= DWT Optimization=

==GCC4 Vector Ops==

GCC supports vectorization, and you can code general vector operations without any assembly. GCC4.0 will automatically convert the vector operations to machine instructions of the defined processor platform. This makes it easy to support several vector processors, like SSE, MMX, ALTIVEC, and simulated.

Here is demo code to accomplish this task with the 9/7 encode; it should achieve at least a 2x speedup: [[User:Dzonatas_Sol/DEMO_DWT]]

==SSE Implementation==

From the author of the below code: Balatoni Denes, dbalatoni at programozo.hu

<blockquote>
I see that openjpeg uses a BSD licence. Yes you can use that code under BSD
licence, thanks for asking too :) . I might not have time to do the
integration myself, but of course I can answer questions if needed.

ps: this code can not do dwt on arbitrary size vectors. if you have k levels
of dwt, than you can only have IIRC vectorsizes of multiplies of 2^k. for
arbitrary size vectors, more coding is needed.
</blockquote>

<pre>
static float coeffs_cdf97_sse[12*4] __attribute__ ((__aligned__ (32))) = {
-1.586134342,-1.586134342,-1.586134342,-1.586134342,
-0.052980118,-0.052980118,-0.052980118,-0.052980118,
0.882911075, 0.882911075, 0.882911075, 0.882911075,
0.443506852, 0.443506852, 0.443506852, 0.443506852,
-1.230174105,-1.230174105,-1.230174105,-1.230174105,
0.812893066, 0.812893066, 0.812893066, 0.812893066,
1.230174105, 1.230174105, 1.230174105, 1.230174105,
-0.812893066,-0.812893066,-0.812893066,-0.812893066,
-0.443506852,-0.443506852,-0.443506852,-0.443506852,
-0.882911075,-0.882911075,-0.882911075,-0.882911075,
0.052980118, 0.052980118, 0.052980118, 0.052980118,
1.586134342, 1.586134342, 1.586134342, 1.586134342
};

#define HORIZ_LIFTING_STEP8(i1, i2, o1, o2, ofs, o2b) \
"movaps " #ofs "(%2), %%xmm5 \n\t" \
"movaps " #i1 ", " #o2 " \n\t" \
"shufps $147, %%xmm7, %%xmm7 \n\t" \
"shufps $147, " #o2 ", " #o2 " \n\t" \
"movss %%xmm7, %%xmm0 \n\t" \
"movss " #o2 ", %%xmm7 \n\t" \
"movss %%xmm0, " #o2 " \n\t" \
"addps " #o2b ", " #o1 " \n\t" \
"mulps %%xmm5, " #o1 " \n\t" \
"addps " #i2 ", " #o1 " \n\t"

#define HORIZ_LIFTING_STEP8_END(i1, i2, o1, o2, ofs, o2b) \
"movaps " #ofs "(%2), %%xmm5 \n\t" \
"movaps " #i1 ", " #o2 " \n\t" \
"shufps $147, %%xmm7, %%xmm7 \n\t" \
"shufps $147, " #o2 ", " #o2 " \n\t" \
"movss %%xmm7, " #o2 " \n\t" \
"addps " #o2b ", " #o1 " \n\t" \
"mulps %%xmm5, " #o1 " \n\t" \
"addps " #i2 ", " #o1 " \n\t"

#define HORIZ_LIFTING_STEP8_BEGIN(i1, i2, o1, o2, ofs, o2b, shu) \
"movaps " #ofs "(%2), %%xmm5 \n\t" \
"movaps " #i1 ", " #o2 " \n\t" \
"shufps $147, %%xmm7, %%xmm7 \n\t" \
"shufps $147, " #o2 ", " #o2 " \n\t" \
"movss " #o2 ", %%xmm7 \n\t" \
"shufps " #shu ", " #o2 ", " #o2 " \n\t" \
"addps " #o2b ", " #o1 " \n\t" \
"mulps %%xmm5, " #o1 " \n\t" \
"addps " #i2 ", " #o1 " \n\t"

#define HORIZ_LIFTING_STEP16(i1, i2, i3, i4, o1, o2, o3, o4, ofs, o3b, o4b) \
"movaps " #i2 ", " #o4 " \n\t" \
"movaps " #i1 ", " #o3 " \n\t" \
"shufps $147, %%xmm7, %%xmm7 \n\t" \
"shufps $147, " #o4 ", " #o4 " \n\t" \
"shufps $147, " #o3 ", " #o3 " \n\t" \
"movss %%xmm7, %%xmm0 \n\t" \
"movss " #o4 ", %%xmm7 \n\t" \
"movss " #o3 ", " #o4 " \n\t" \
"movss %%xmm0, " #o3 " \n\t" \
"movaps " #ofs "(%2), %%xmm0 \n\t" \
"addps " #o3b ", " #o1 " \n\t" \
"addps " #o4b ", " #o2 " \n\t" \
"mulps %%xmm0, " #o1 " \n\t" \
"mulps %%xmm0, " #o2 " \n\t" \
"addps " #i3 ", " #o1 " \n\t" \
"addps " #i4 ", " #o2 " \n\t"

/* Calculate 4 lifting steps to get 2 samples vertical, xmm0-xmm3 : buffer
*/

#define VERT_MAIN(in1, in2, ofs) \
"movaps " #ofs "(%2), %%xmm7 \n\t" \
\
"movaps " #in1 ", %%xmm4 \n\t" \
"movaps %%xmm0, %%xmm5 \n\t" \
"addps %%xmm4, %%xmm5 \n\t" \
"mulps %%xmm7, %%xmm5 \n\t" \
"addps " #in2 ", %%xmm5 \n\t" \
\
"movaps 16+" #ofs "(%2), %%xmm7 \n\t" \
\
"movaps %%xmm5, %%xmm6 \n\t" \
"addps %%xmm1, %%xmm6 \n\t" \
"mulps %%xmm7, %%xmm6 \n\t" \
"addps %%xmm0, %%xmm6 \n\t" \
\
"movaps 32+" #ofs "(%2), %%xmm7 \n\t" \
"movaps %%xmm4, %%xmm0 \n\t" \
\
"movaps %%xmm6, %%xmm4 \n\t" \
"addps %%xmm2, %%xmm4 \n\t" \
"mulps %%xmm7, %%xmm4 \n\t" \
"addps %%xmm1, %%xmm4 \n\t" \
\
"movaps 48+" #ofs "(%2), %%xmm7 \n\t" \
"movaps %%xmm5, %%xmm1 \n\t" \
\
"movaps %%xmm4, %%xmm5 \n\t" \
"addps %%xmm3, %%xmm5 \n\t" \
"mulps %%xmm7, %%xmm5 \n\t" \
"addps %%xmm2, %%xmm5 \n\t" \
\
"movaps %%xmm4, %%xmm3 \n\t" \
"movaps %%xmm6, %%xmm2 \n\t"

static inline void analyze_inplace(float *in, float *coeffs, int step, int iter) {
int lof1, lof2;

asm volatile(
// Anal_begin
"movaps (%1), %%xmm7 \n\t"
"movaps (%1), %%xmm1 \n\t"
"movaps (%1), %%xmm0 \n\t"
"movaps (%1), %%xmm2 \n\t"
"shufps $1, %%xmm1, %%xmm1 \n\t"
"shufps $2, %%xmm7, %%xmm7 \n\t"

"movaps (%2), %%xmm5 \n\t"
"addss %%xmm7, %%xmm0 \n\t"
"mulss %%xmm5, %%xmm0 \n\t"
"addss %%xmm1, %%xmm0 \n\t"

"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm0, %%xmm7 \n\t"

"movaps 16(%2), %%xmm5 \n\t"
"addss %%xmm0, %%xmm0 \n\t"
"mulss %%xmm5, %%xmm0 \n\t"
"addss %%xmm2, %%xmm0 \n\t"

"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm0, %%xmm7 \n\t"
"shufps $147, %%xmm7, %%xmm7 \n\t"

"movaps (%1, %5), %%xmm1 \n\t"
"movaps (%1, %5, 2), %%xmm0 \n\t"
"movaps %%xmm1, %%xmm2 \n\t"
"movups 12(%1), %%xmm4 \n\t"
"shufps $221, %%xmm0, %%xmm1 \n\t"
"shufps $136, %%xmm0, %%xmm2 \n\t"
"shufps $147, %%xmm1, %%xmm1 \n\t"
"movss %%xmm4, %%xmm1 \n\t"

HORIZ_LIFTING_STEP8(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 0, %%xmm3)
HORIZ_LIFTING_STEP8(%%xmm2, %%xmm3, %%xmm2, %%xmm1, 16, %%xmm1)
HORIZ_LIFTING_STEP8(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 32, %%xmm3)
HORIZ_LIFTING_STEP8_BEGIN(%%xmm2, %%xmm3, %%xmm1, %%xmm1, 48, %%xmm2, $229)

"movaps 64(%2), %%xmm6 \n\t"
"mulps %%xmm6, %%xmm2 \n\t"
"movaps 80(%2), %%xmm5 \n\t"
"mulps %%xmm5, %%xmm1 \n\t"

"movaps %%xmm1, (%1) \n\t"
"movaps %%xmm2, (%1, %5) \n\t"

"addl %5, %1 \n\t"
"addl %5, %1 \n\t"

//Anal sse16
".balign 16 \n\t"
"1: \n\t"
"movaps (%1, %5), %%xmm1 \n\t"
"movaps (%1, %5, 2), %%xmm0 \n\t"
"movaps (%1, %6), %%xmm4 \n\t"
"movaps (%1, %5, 4), %%xmm6 \n\t"
"movaps %%xmm1, %%xmm2 \n\t"
"movaps %%xmm4, %%xmm5 \n\t"
"shufps $221, %%xmm0, %%xmm1 \n\t"
"shufps $221, %%xmm6, %%xmm4 \n\t"
"shufps $136, %%xmm0, %%xmm2 \n\t"
"shufps $136, %%xmm6, %%xmm5 \n\t"
"shufps $147, %%xmm1, %%xmm1 \n\t"
"shufps $147, %%xmm4, %%xmm4 \n\t"
"movups 12(%1), %%xmm3 \n\t"
"movss %%xmm3, %%xmm1 \n\t"
"movups 12(%1, %5, 2), %%xmm3 \n\t"
"movss %%xmm3, %%xmm4 \n\t"

HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm1, %%xmm4, %%xmm2, %%xmm5, %%xmm3, %%xmm6, 0, %%xmm3, %%xmm6)
HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm3, %%xmm6, %%xmm2, %%xmm5, %%xmm1, %%xmm4, 16, %%xmm1, %%xmm4)
HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm1, %%xmm4, %%xmm2, %%xmm5, %%xmm3, %%xmm6, 32, %%xmm3, %%xmm6)
HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm3, %%xmm6, %%xmm1, %%xmm4, %%xmm1, %%xmm4, 48, %%xmm2, %%xmm5)

"movaps 64(%2), %%xmm0 \n\t"
"movaps 80(%2), %%xmm6 \n\t"
"mulps %%xmm0, %%xmm2 \n\t"
"mulps %%xmm0, %%xmm5 \n\t"
"mulps %%xmm6, %%xmm1 \n\t"
"mulps %%xmm6, %%xmm4 \n\t"

"movaps %%xmm1, (%1) \n\t"
"movaps %%xmm2, (%1, %5) \n\t"
"movaps %%xmm4, (%1, %5, 2) \n\t"
"movaps %%xmm5, (%1, %6) \n\t"

"addl %6, %1 \n\t"
"addl %5, %1 \n\t"
"subl $1, %0 \n\t"
"jnz 1b \n\t"

//Anal_end

"movaps 16-16(%1, %5), %%xmm1 \n\t"
"movaps 16-16(%1, %5), %%xmm0 \n\t"
"shufps $6, %%xmm0, %%xmm0 \n\t" //27 volt
"movaps %%xmm1, %%xmm2 \n\t"
"movups 12(%1), %%xmm4 \n\t"
"shufps $221, %%xmm0, %%xmm1 \n\t"
"shufps $136, %%xmm0, %%xmm2 \n\t"
"shufps $147, %%xmm1, %%xmm1 \n\t"
"movss %%xmm4, %%xmm1 \n\t"

HORIZ_LIFTING_STEP8_END(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 0, %%xmm3)
HORIZ_LIFTING_STEP8_END(%%xmm2, %%xmm3, %%xmm2, %%xmm1, 16, %%xmm1)
HORIZ_LIFTING_STEP8_END(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 32, %%xmm3)
HORIZ_LIFTING_STEP8_END(%%xmm2, %%xmm3, %%xmm1, %%xmm1, 48, %%xmm2)

"movaps 64(%2), %%xmm7 \n\t"
"mulps %%xmm7, %%xmm2 \n\t"
"movaps 80(%2), %%xmm5 \n\t"
"mulps %%xmm5, %%xmm1 \n\t"

"movaps %%xmm1, 0(%1) \n\t"
"movaps %%xmm2, 16-16(%1, %5) \n\t"

: "=r" (lof1), "=r" (lof2)
: "r" (coeffs), "1" (in), "0" (iter), "r" (step) , "r" (step*3)
);
}

static inline void synthetize_inplace(float *in, float *coeffs, int step, int iter) {
int lof1, lof2;

asm volatile(
//Synth_begin
"movaps (%1), %%xmm1 \n\t"
"movaps (%1, %5), %%xmm2 \n\t"

"movaps 96(%2), %%xmm5 \n\t"
"mulps %%xmm5, %%xmm1 \n\t"
"movaps 112(%2), %%xmm5 \n\t"
"mulps %%xmm5, %%xmm2 \n\t"

HORIZ_LIFTING_STEP8_BEGIN(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 128, %%xmm3, $229)
HORIZ_LIFTING_STEP8_BEGIN(%%xmm2, %%xmm3, %%xmm2, %%xmm1, 128+16, %%xmm1, $230)
HORIZ_LIFTING_STEP8_BEGIN(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 128+32, %%xmm3, $228)
HORIZ_LIFTING_STEP8_BEGIN(%%xmm2, %%xmm3, %%xmm2, %%xmm1, 128+48, %%xmm1, $228)

"unpckhps %%xmm2, %%xmm1 \n\t"
"movaps %%xmm1, (%1) \n\t"

"addl %5, %1 \n\t"

//Synth_sse16
".balign 16 \n\t"
"1: \n\t"
"movaps (%1, %5), %%xmm1 \n\t"
"movaps (%1, %5, 2), %%xmm2 \n\t"
"movaps (%1, %6), %%xmm4 \n\t"
"movaps (%1, %5, 4), %%xmm5 \n\t"

"movaps 96(%2), %%xmm0 \n\t"
"mulps %%xmm0, %%xmm1 \n\t"
"mulps %%xmm0, %%xmm4 \n\t"
"movaps 112(%2), %%xmm0 \n\t"
"mulps %%xmm0, %%xmm2 \n\t"
"mulps %%xmm0, %%xmm5 \n\t"

HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm1, %%xmm4, %%xmm2, %%xmm5, %%xmm3, %%xmm6, 128, %%xmm3, %%xmm6)
HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm3, %%xmm6, %%xmm2, %%xmm5, %%xmm1, %%xmm4, 128+16, %%xmm1, %%xmm4)
HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm1, %%xmm4, %%xmm2, %%xmm5, %%xmm3, %%xmm6, 128+32, %%xmm3, %%xmm6)
HORIZ_LIFTING_STEP16(%%xmm2, %%xmm5, %%xmm3, %%xmm6, %%xmm2, %%xmm5, %%xmm1, %%xmm4, 128+48, %%xmm1, %%xmm4)

"movaps %%xmm1, %%xmm3 \n\t"
"movaps %%xmm4, %%xmm6 \n\t"

"unpckhps %%xmm2, %%xmm3 \n\t"
"unpcklps %%xmm2, %%xmm1 \n\t"
"unpckhps %%xmm5, %%xmm6 \n\t"
"unpcklps %%xmm5, %%xmm4 \n\t"
"movaps %%xmm1, (%1) \n\t"
"movaps %%xmm3, (%1, %5) \n\t"
"movaps %%xmm4, (%1, %5, 2) \n\t"
"movaps %%xmm6, (%1, %6) \n\t"

"addl %5, %1 \n\t"
"addl %6, %1 \n\t"
"subl $1, %0 \n\t"
"jnz 1b \n\t"

//Synthend_sse
"movaps (%1, %5), %%xmm1 \n\t"
"movaps (%1, %5, 2), %%xmm2 \n\t"

"movaps 96(%2), %%xmm5 \n\t"
"mulps %%xmm5, %%xmm1 \n\t"
"movaps 112(%2), %%xmm5 \n\t"
"mulps %%xmm5, %%xmm2 \n\t"

HORIZ_LIFTING_STEP8(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 128, %%xmm3)
HORIZ_LIFTING_STEP8(%%xmm2, %%xmm3, %%xmm2, %%xmm1, 128+16, %%xmm1)
HORIZ_LIFTING_STEP8(%%xmm2, %%xmm1, %%xmm2, %%xmm3, 128+32, %%xmm3)
HORIZ_LIFTING_STEP8(%%xmm2, %%xmm3, %%xmm2, %%xmm1, 128+48, %%xmm1)

"movaps %%xmm1, %%xmm3 \n\t"

"unpckhps %%xmm2, %%xmm3 \n\t"
"unpcklps %%xmm2, %%xmm1 \n\t"
"movaps %%xmm1, (%1) \n\t"
"movaps %%xmm3, (%1, %5) \n\t"

// Vege
"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm7, %%xmm1 \n\t"

"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm7, %%xmm2 \n\t"
"movss %%xmm7, %%xmm3 \n\t"
"movaps 128+16(%2), %%xmm5 \n\t"
"addss %%xmm2, %%xmm2 \n\t"
"mulss %%xmm5, %%xmm2 \n\t"
"addss %%xmm1, %%xmm2 \n\t"
"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm7, %%xmm1 \n\t"
"movss %%xmm7, %%xmm4 \n\t"
"movaps 128+32(%2), %%xmm5 \n\t"
"addss %%xmm2, %%xmm4 \n\t"
"mulss %%xmm5, %%xmm4 \n\t"
"addss %%xmm3, %%xmm4 \n\t"
"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm7, %%xmm0 \n\t"

"addss %%xmm4, %%xmm0 \n\t"
"movaps 128+48(%2), %%xmm5 \n\t"
"mulss %%xmm5, %%xmm0 \n\t"
"addss %%xmm1, %%xmm0 \n\t"

"movss %%xmm4, %%xmm6 \n\t"
"addss %%xmm6, %%xmm6 \n\t"
"mulss %%xmm5, %%xmm6 \n\t"
"addss %%xmm6, %%xmm2 \n\t"

"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm2, %%xmm7 \n\t"
"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm4, %%xmm7 \n\t"
"shufps $147, %%xmm7, %%xmm7 \n\t"
"movss %%xmm0, %%xmm7 \n\t"
"shufps $147, %%xmm7, %%xmm7 \n\t"

"movups %%xmm7, (%1, %5, 2) \n\t"

: "=r" (lof1), "=r" (lof2)
: "r" (coeffs), "1" (in), "0" (iter), "r" (step) , "r" (step*3)
);
}

static inline void analyze_inplace_vertical(float *in, float *coeffs, int step, int iter) {
int lof1, lof2;

asm volatile(
// A_Start
"movaps (%2), %%xmm7 \n\t"

"movaps (%1, %5, 4), %%xmm0 \n\t"
"movaps (%1, %5, 2), %%xmm1 \n\t"
"addps %%xmm0, %%xmm1 \n\t"
"mulps %%xmm7, %%xmm1 \n\t"
"addps (%1, %6), %%xmm1 \n\t"

"movaps (%1), %%xmm4 \n\t"
"addps (%1, %5, 2), %%xmm4 \n\t"
"mulps %%xmm7, %%xmm4 \n\t"
"addps (%1, %5), %%xmm4 \n\t"

"movaps 16(%2), %%xmm7 \n\t"

"movaps %%xmm1, %%xmm2 \n\t"
"addps %%xmm4, %%xmm2 \n\t"
"mulps %%xmm7, %%xmm2 \n\t"
"addps (%1, %5, 2), %%xmm2 \n\t"

"movaps %%xmm4, %%xmm5 \n\t"
"addps %%xmm4, %%xmm5 \n\t"
"mulps %%xmm7, %%xmm5 \n\t"
"addps (%1), %%xmm5 \n\t"

"movaps 32(%2), %%xmm7 \n\t"

"movaps %%xmm5, %%xmm3 \n\t"
"addps %%xmm2, %%xmm3 \n\t"
"mulps %%xmm7, %%xmm3 \n\t"
"addps %%xmm4, %%xmm3 \n\t"

"movaps 48(%2), %%xmm7 \n\t"

"movaps %%xmm3, %%xmm6 \n\t"
"addps %%xmm3, %%xmm6 \n\t"
"mulps %%xmm7, %%xmm6 \n\t"
"addps %%xmm5, %%xmm6 \n\t"

"movaps 64(%2), %%xmm4 \n\t"
"movaps 80(%2), %%xmm5 \n\t"
"mulps %%xmm3, %%xmm4 \n\t"
"mulps %%xmm5, %%xmm6 \n\t"

"movaps %%xmm6, (%1) \n\t"
"movaps %%xmm4, (%1, %5) \n\t"

"addl %5, %1 \n\t"
"addl %5, %1 \n\t"

// A_Main
".balign 16 \n\t"
"1: \n\t"

VERT_MAIN((%1, %5, 4), (%1, %6), 0)

"movaps 64(%2), %%xmm7 \n\t"
"movaps 80(%2), %%xmm6 \n\t"

"mulps %%xmm7, %%xmm4 \n\t"
"mulps %%xmm6, %%xmm5 \n\t"

"movaps %%xmm5, (%1) \n\t"
"movaps %%xmm4, (%1, %5) \n\t"

"addl %5, %1 \n\t"
"addl %5, %1 \n\t"
"subl $2, %0 \n\t"
"jnz 1b \n\t"

// A_End
VERT_MAIN(%%xmm0, (%1, %6), 0)

"movaps 64(%2), %%xmm7 \n\t"
"movaps 80(%2), %%xmm6 \n\t"

"mulps %%xmm7, %%xmm4 \n\t"
"mulps %%xmm6, %%xmm5 \n\t"

"movaps (%1, %5), %%xmm6 \n\t"
"movaps %%xmm4, (%1, %5) \n\t"
"movaps (%1), %%xmm4 \n\t"
"movaps %%xmm5, (%1) \n\t"

VERT_MAIN(%%xmm4, %%xmm6, 0)

"movaps 64(%2), %%xmm7 \n\t"
"movaps 80(%2), %%xmm6 \n\t"

"mulps %%xmm7, %%xmm4 \n\t"
"mulps %%xmm6, %%xmm5 \n\t"

"movaps %%xmm5, (%1, %5, 2) \n\t"
"movaps %%xmm4, (%1, %6) \n\t"

: "=r" (lof1), "=r" (lof2)
: "r" (coeffs), "1" (in), "0" (iter), "r" (step) , "r" (step*3)
);
}

static inline void synthetize_inplace_vertical(float *in, float *coeffs, int step, int iter) {
int lof1, lof2;

asm volatile(
// S_Start
"movaps 128(%2), %%xmm7 \n\t"
"movaps 112(%2), %%xmm5 \n\t"
"movaps 96(%2), %%xmm4 \n\t"
"movaps %%xmm5, %%xmm0 \n\t"
"movaps %%xmm4, %%xmm6 \n\t"
"mulps (%1, %5), %%xmm5 \n\t"
"mulps (%1, %6), %%xmm0 \n\t"
"mulps (%1, %5, 2), %%xmm4 \n\t"
"mulps (%1), %%xmm6 \n\t"

"movaps %%xmm5, %%xmm1 \n\t"
"addps %%xmm0, %%xmm1 \n\t"
"mulps %%xmm7, %%xmm1 \n\t"
"addps %%xmm4, %%xmm1 \n\t"

"movaps %%xmm5, %%xmm4 \n\t"
"addps %%xmm4, %%xmm4 \n\t"
"mulps %%xmm7, %%xmm4 \n\t"
"addps %%xmm6, %%xmm4 \n\t"

"movaps 128+16(%2), %%xmm7 \n\t"

"movaps %%xmm1, %%xmm2 \n\t"
"addps %%xmm4, %%xmm2 \n\t"
"mulps %%xmm7, %%xmm2 \n\t"
"addps %%xmm5, %%xmm2 \n\t"

"movaps 128+32(%2), %%xmm7 \n\t"

"movaps %%xmm2, %%xmm3 \n\t"
"addps %%xmm3, %%xmm3 \n\t"
"mulps %%xmm7, %%xmm3 \n\t"
"addps %%xmm4, %%xmm3 \n\t"

"movaps %%xmm3, (%1) \n\t"

"addl %5, %1 \n\t"

// S_Main
".balign 16 \n\t"
"1: \n\t"

"movaps 96(%2), %%xmm6 \n\t"
"movaps 112(%2), %%xmm4 \n\t"

"mulps (%1, %5, 4), %%xmm4 \n\t"
"mulps (%1, %6), %%xmm6 \n\t"

VERT_MAIN(%%xmm4, %%xmm6, 128)

"movaps %%xmm5, (%1) \n\t"
"movaps %%xmm4, (%1, %5) \n\t"

"addl %5, %1 \n\t"
"addl %5, %1 \n\t"
"subl $2, %0 \n\t"
"jnz 1b \n\t"

// S_End
"movaps %%xmm1, %%xmm4 \n\t"
"movaps 128+16(%2), %%xmm7 \n\t"
"addps %%xmm1, %%xmm4 \n\t"
"mulps %%xmm7, %%xmm4 \n\t"
"addps %%xmm0, %%xmm4 \n\t"

"movaps %%xmm2, %%xmm5 \n\t"
"movaps 128+32(%2), %%xmm7 \n\t"
"addps %%xmm4, %%xmm5 \n\t"
"mulps %%xmm7, %%xmm5 \n\t"
"addps %%xmm1, %%xmm5 \n\t"

"movaps %%xmm3, %%xmm6 \n\t"
"movaps 128+48(%2), %%xmm7 \n\t"
"addps %%xmm5, %%xmm6 \n\t"
"mulps %%xmm7, %%xmm6 \n\t"
"addps %%xmm2, %%xmm6 \n\t"

"movaps %%xmm5, %%xmm0 \n\t"
"addps %%xmm5, %%xmm0 \n\t"
"mulps %%xmm7, %%xmm0 \n\t"
"addps %%xmm4, %%xmm0 \n\t"

"movaps %%xmm6, (%1) \n\t"
"movaps %%xmm5, (%1, %5) \n\t"
"movaps %%xmm0, (%1, %5, 2) \n\t"

: "=r" (lof1), "=r" (lof2)
: "r" (coeffs), "1" (in), "0" (iter), "r" (step) , "r" (step*3)
);
}

int dwt1d(float *pict, int width, int height, int it) {
int h;

for(h=1;h<(1<<it);h<<=1)
analyze_inplace(pict, coeffs_cdf97_sse, 16*h, (width/16/h)-1);
}

int idwt1d(float *pict, int width, int height, int it) {
int h;

for(h=(1<<(it-1));h>0;h>>=1)
synthetize_inplace(pict, coeffs_cdf97_sse, 16*h, (width/h/16)-1);
}

int dwt2d(float *pict, int width, int height, int it) {
int i,h;
float *p;

for(h=1;h<(1<<it);h<<=1) {

for(p=pict,i=0;i<height;i+=h, p+=width*h)
analyze_inplace(p, coeffs_cdf97_sse, 16*h, (width/16/h)-1);

for(p=pict, i=0;i<width;i+=4*h, p+=4*h)
analyze_inplace_vertical(p, coeffs_cdf97_sse, width*4*h, (height/h)-6);
}
}

int idwt2d(float *pict, int width, int height, int it) {
int i, h;
float *p;

for(h=(1<<(it-1));h>0;h>>=1) {
for(p=pict, i=0;i<width;i+=4*h, p+=4*h)
synthetize_inplace_vertical(p, coeffs_cdf97_sse, width*4*h, (height/h)-4);

for(p=pict,i=0;i<height;i+=h, p+=width*h)
synthetize_inplace(p, coeffs_cdf97_sse, 16*h, (width/h/16)-1);
}
}

</pre>

[[Category:Feature Requests]]

SLDev-Traffic 1

2007-03-03T18:01:05Z

SpacedOut Frye: self correction

sldev-traffic no 1

[[Image:sldev-traffic.gif|SLDev Traffic]]

sldev discussions through March 2, 2007

== Executable Switcher ==

Noting that plugins will take a while to mature and that distributing new features for testing was desirable, Dale Glass proposed a system for selecting among multiple viewer versions at launch time:
Since most people don't have nearly the bandwidth capabilities of
LL, making things compact is important. For that reason, alternative
clients will be distributed in say, NSIS packages, but include only
the changed files, as well as some metadata. The metadata indicates
among other things on which LL release it's based.

Switcher will assemble a working SL install based on the original
files and the modifications from the installed package, then run
that.

If the third party client is based on a SL version that's not
installed (say, firstlook based and user is running the stable
client), then the switcher will try to automatically download the
official version to use as a base.

Peekay Semyorka wondered at why a user couldn't install multiple EXEs in the viewer directory. Dale Glass noted that viewers may have different and incompatible data, such as the modified XML menus in his own scanner.

Dale Glass emphasized that this is a temporary solution until plugins are ready.

== Viewer Manifest ==

In the Executable Switcher thread, Ryan Williams noted that he would introduce a Python-based installer packaging script in the next release, which came with the beta release this week. The documentation is here:
https://wiki.secondlife.com/wiki/Viewer_Manifest

Rob Lanphier invited feedback on Ryan Williams' script, noting that engaging Lindens productively (Ryan Williams is a Linden) is a good way to encourage Lindens to reciprocate.

Christian Westbrook inquired about whether the packaging script would be GPL'd, noting current work in deploying OpenSL with the NullSoft packaging system. Yes on the GPL.

== LLMozLib ==

Tofu Linden announced the upload of LLMozLib/uBrowser
LLMozLib is a library (and set of Mozilla patches) written by Callum
and others which we use to create our embedded Mozilla widgets inside
the Second Life viewer (for web profiles, F1 Help, and the login
screen currently) with a simplified API. It does not depend upon the
Second Life source and can be used in your own programs.

For more info about LLMozLib and uBrowser, see http://ubrowser.com/

Linux users had some remaining trouble building Second Life with Mozilla enabled, and Signore Iredell posted instructions for building without browser support: https://lists.secondlife.com/pipermail/sldev/2007-February/000532.html

Tofu Linden noted that he had committed a change to make disabling LLMozLib easier, and that it should reach the open source release soon.

== C++ bindings Prototype versus C ==

Tim Shephard posted a C++ prototype which proved that it was possible to develop a plugin API which interfaced via C++ and inheritance. However, the issues he ran into were that you would need to build with the same compiler (both client and plugin) in order to develop compatible binaries. This was a significant non starter.

He also discussed the NPAPI API as a simple model for plugins.

== C++ motivated Plugin Bindings ==

Soft Noel posted C++ motivated bindings that could be used as a plugin prototype. It can load plugins as libraries and negotiate multiple versions of an interface for later compatibility. The first version is Intel Mac only, but includes work toward other architectures.

The significant concern as pointed out by Tim Shephard in an earlier posting as mentioned above, is that C++ has significant Application Binary Issues on the Windows platform. (Microsoft has not guaranteed that they will support the C++ ABI from one release to the next (in fact, it changed in VS2003 -> VS2005)). This will make it difficult to support people who build their plugins with a different compiler than what Linden Lab is using.

Argent Stonecutter suggested that the bindings should be as language-neutral as possible, noting that targeting C was targeting the lowest common denominator of all languages. Soft Noel is reworking the posted system to offer a C interface instead of C++. Argent Stonecutter voiced concern about the anonymous pointers C would introduce in the plugin API and referenced an older thread. In that thread, he laid out one scheme for encoding plugin parameter formats and described the behavior plugins would follow in validating such a plugin interface. Ryan Williams suggested that the already existent LLSD would work for a plugin interface with this design and noted likely similarity between a plugin API and the messaging system.

== Keep It Simple ==

Soft Noel suggested the ability for plugins to unload on request from a sim, should a plugin malfunction and create problems for the grid. There was much discussion about the non-desirability of such a feature, and Kelly Washington reiterated Rob Lanphier's call to keep things simple up front. Rob Lanphier linked to http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html and Kelly Washington wrote:
There will have to be a line drawn somewhere between what can be a
plugin and what requires a separate client or re-compile. This
line does not need to be fixed in stone at the creation of the
plugin system. In fact the best approach may be to start
conservatively with very little on the plugin side. This would
allow the system to get out, get tested, get used and get
refined quicker than building an all-encompassing plugin system
from the start.
...
what is the minimal needed to create a plugin system that can at
least make some useful plugins?

My guess is the following:
- create a floater, be able to populate and update data in the
floater. By this I just mean set text, set images, add/remove
items from scroll lists.
- add UI to bring up the floater. As a first pass even just a
'plugins' menu with a menu item for each loaded plug in.
- access to specific internal data - ie the list of visible avatars,
region name, current location etc

Now that won't let you create just any plugin, it won't even let you
create most plugins (I'm sure everyone noticed there is nothing about
handling messages at all), but that is my guess as to the minimal
needed by a plugin.

== Plugin Autoupdater ==

A developer suggested that the plugin system should support automatic updates from plugin authors' sites. The primary reason given was the headache of supporting thousands of users who might seek help from the plugin author every time a Viewer update broke old plugins.

Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.

== Two Source Releases ==

Rob Lanphier announced the release of the First Look 1.13.3.58390 source on Feb 24 and the 1.13.4.3 viewer beta on Feb 28:
https://wiki.secondlife.com/wiki/Source_downloads

Soft Noel noted build problems on the Mac, filing several bug reports and workarounds, however a texture bug continues to make 1.13.4.3 open source builds unusable on an Intel Mac. Others reported similar problems with the Linux build on SLDev and #opensl.

== Second Life viewer packaged for Fedora ==

Callum Lerwick announced an RPM-packaged viewer for Second Life, including library dependencies. He indicated that he had found another user doing duplicate work and suggested they had some merging to do. Packages are here:
http://www.haxxed.com/rpms/secondlife/

== Lip Sync and Gesture Motions ==

One plugin feature discussed was lip sync and gesture motions. Phoenix Linden wrote:
Just so everyone knows, we are already working on lip and gesture
motions for the avatar. This is no promise of functionality or
when it will be available, but it is in the pipeline and under
active development.

Later in the week, Mike Monkowski noted a C|Net article regarding Linden Lab's announcement of Vivox voice support:
http://news.com.com/Integrated+voice+coming+to+Second+Life/2100-1043_3-6162410.html?tag=nefd.top

== Stereoscopic Viewer ==

Eric Maslowski noted that the University of Michigan 3D lab was working on a stereoscopic 3D viewer:
http://um3d.dc.umich.edu/

Many of the questions in his announcement remained unanswered:
https://lists.secondlife.com/pipermail/sldev/2007-February/000612.html

== Agni, Aditi, and Uma ==

Dale Glass inquired about the grids available for Viewer developers. Joshua Bell replied, listing the three grids as Agni (live grid), Aditi (beta) and Uma (open source developers). Fuller details were included in Joshua Bell's response:
https://lists.secondlife.com/pipermail/sldev/2007-February/000618.html

== LSL Instantiated Prim Metadata ==

There has been a continuing discussion about the desirability of a custom data field that LSL could set on prims, and which Viewer developers could use for representing features not yet implemented on the server. Jason Giglio summarized the feature with an example use:
https://lists.secondlife.com/pipermail/sldev/2007-February/000644.html

The original Wiki proposal is here:
https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL

There was further discussion about whether an arbitrary named attribute system was desirable. In #opensl discussions it was noted that named parameters could already be set when communicating with the sim, but nobody voiced any guarantee that the data would persist, or suggested that this data could be set or directly accessed from LSL.

== LSL to Viewer Communications ==

Initially mentioned in the prior thread, Dale Glass mentioned a different system that allowed dynamic communication between a custom viewer and LSL. His details and a pointer to the Viewer source patch are laid out in his message:

https://lists.secondlife.com/pipermail/sldev/2007-February/000582.html

== Unit Testing Feedback Requested ==

Gaurav Sharma requested feedback on what parts of the viewer should be covered by unit testing. Rob Lanphier noted that Gaurav Sharma was working for Adroit, which had been hired for this task. John Hurliman suggested that the LLJoint class has been problematc, but there has been little other relevant feedback. Gaurav Sharma updated the patch with a second version later in the week. That version is here:
http://lists.secondlife.com/pipermail/sldev/attachments/20070302/d8809402/unittest-2-0001.obj

Gaurav Sharma's repeated request for unit test suggestions is here:
https://lists.secondlife.com/pipermail/sldev/2007-March/000695.html

== Linux Viewers and 3D Acceleration ==

Truxpin was having difficulty making Second Life run on his machine using open source nVidia drivers. David Fries states that Linden Lab currently requires a 24 bit depth buffer, while Mesa only supports 16 bit depth. David Fries (SpacedOut Frye) offered a patch that would request an OpenGL context with a 16 bit depth buffer if the 24 bit depth buffer request failed.

Truxpin posted an e-mail including glxinfo which showed,
direct rendering: No
server glx vendor string: SGI
Indicating he only had software OpenGL rendering available. The patch allowed the Second Life viewer to run with a 0.7 frame rate which also indicated software rendering.

Truxpin later posted (off list) that he was able to get the nVidia driver installed and running at about the same speed under Linux as Windows on that computer.

nVidia users currently require the closed source driver for 3D OpenGL acceleration.

== Linden Lab and Open Source ==

Christian Westbrook stated that Linden Lab had not yet completely accepted open source development. Rob Lanphier posted a response detailing the extent of Linden Lab's contributions and some of the remaining legal and business hurdles Linden Lab is working to move out of the way.

Rob Lanphier repeats emphasis on the necessity for list contributors to sign contributor agreements in order to free Linden Lab employees to more directly interact with SLDev members.

== Plugin Source Licensing ==

SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.

== OpenJPEG patch (see VWR-123) still not merged ==

Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.
David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123 on jira which was first posted February 11th, and again asked why it hasn't made it into the source code release.

David Fries posted a correction to his response. VWR-94 was the earlier patch to fix this buffer overflow which was posted a full month ago on February 3rd. It has been obsoleted by VWR-123 though.

SLDev-Traffic 1

2007-03-03T17:29:16Z

SpacedOut Frye: added OpenJPEG patch (see VWR-123) still not merged

sldev-traffic no 1

[[Image:sldev-traffic.gif|SLDev Traffic]]

sldev discussions through March 2, 2007

== Executable Switcher ==

Noting that plugins will take a while to mature and that distributing new features for testing was desirable, Dale Glass proposed a system for selecting among multiple viewer versions at launch time:
Since most people don't have nearly the bandwidth capabilities of
LL, making things compact is important. For that reason, alternative
clients will be distributed in say, NSIS packages, but include only
the changed files, as well as some metadata. The metadata indicates
among other things on which LL release it's based.

Switcher will assemble a working SL install based on the original
files and the modifications from the installed package, then run
that.

If the third party client is based on a SL version that's not
installed (say, firstlook based and user is running the stable
client), then the switcher will try to automatically download the
official version to use as a base.

Peekay Semyorka wondered at why a user couldn't install multiple EXEs in the viewer directory. Dale Glass noted that viewers may have different and incompatible data, such as the modified XML menus in his own scanner.

Dale Glass emphasized that this is a temporary solution until plugins are ready.

== Viewer Manifest ==

In the Executable Switcher thread, Ryan Williams noted that he would introduce a Python-based installer packaging script in the next release, which came with the beta release this week. The documentation is here:
https://wiki.secondlife.com/wiki/Viewer_Manifest

Rob Lanphier invited feedback on Ryan Williams' script, noting that engaging Lindens productively (Ryan Williams is a Linden) is a good way to encourage Lindens to reciprocate.

Christian Westbrook inquired about whether the packaging script would be GPL'd, noting current work in deploying OpenSL with the NullSoft packaging system. Yes on the GPL.

== LLMozLib ==

Tofu Linden announced the upload of LLMozLib/uBrowser
LLMozLib is a library (and set of Mozilla patches) written by Callum
and others which we use to create our embedded Mozilla widgets inside
the Second Life viewer (for web profiles, F1 Help, and the login
screen currently) with a simplified API. It does not depend upon the
Second Life source and can be used in your own programs.

For more info about LLMozLib and uBrowser, see http://ubrowser.com/

Linux users had some remaining trouble building Second Life with Mozilla enabled, and Signore Iredell posted instructions for building without browser support: https://lists.secondlife.com/pipermail/sldev/2007-February/000532.html

Tofu Linden noted that he had committed a change to make disabling LLMozLib easier, and that it should reach the open source release soon.

== C++ bindings Prototype versus C ==

Tim Shephard posted a C++ prototype which proved that it was possible to develop a plugin API which interfaced via C++ and inheritance. However, the issues he ran into were that you would need to build with the same compiler (both client and plugin) in order to develop compatible binaries. This was a significant non starter.

He also discussed the NPAPI API as a simple model for plugins.

== C++ motivated Plugin Bindings ==

Soft Noel posted C++ motivated bindings that could be used as a plugin prototype. It can load plugins as libraries and negotiate multiple versions of an interface for later compatibility. The first version is Intel Mac only, but includes work toward other architectures.

The significant concern as pointed out by Tim Shephard in an earlier posting as mentioned above, is that C++ has significant Application Binary Issues on the Windows platform. (Microsoft has not guaranteed that they will support the C++ ABI from one release to the next (in fact, it changed in VS2003 -> VS2005)). This will make it difficult to support people who build their plugins with a different compiler than what Linden Lab is using.

Argent Stonecutter suggested that the bindings should be as language-neutral as possible, noting that targeting C was targeting the lowest common denominator of all languages. Soft Noel is reworking the posted system to offer a C interface instead of C++. Argent Stonecutter voiced concern about the anonymous pointers C would introduce in the plugin API and referenced an older thread. In that thread, he laid out one scheme for encoding plugin parameter formats and described the behavior plugins would follow in validating such a plugin interface. Ryan Williams suggested that the already existent LLSD would work for a plugin interface with this design and noted likely similarity between a plugin API and the messaging system.

== Keep It Simple ==

Soft Noel suggested the ability for plugins to unload on request from a sim, should a plugin malfunction and create problems for the grid. There was much discussion about the non-desirability of such a feature, and Kelly Washington reiterated Rob Lanphier's call to keep things simple up front. Rob Lanphier linked to http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html and Kelly Washington wrote:
There will have to be a line drawn somewhere between what can be a
plugin and what requires a separate client or re-compile. This
line does not need to be fixed in stone at the creation of the
plugin system. In fact the best approach may be to start
conservatively with very little on the plugin side. This would
allow the system to get out, get tested, get used and get
refined quicker than building an all-encompassing plugin system
from the start.
...
what is the minimal needed to create a plugin system that can at
least make some useful plugins?

My guess is the following:
- create a floater, be able to populate and update data in the
floater. By this I just mean set text, set images, add/remove
items from scroll lists.
- add UI to bring up the floater. As a first pass even just a
'plugins' menu with a menu item for each loaded plug in.
- access to specific internal data - ie the list of visible avatars,
region name, current location etc

Now that won't let you create just any plugin, it won't even let you
create most plugins (I'm sure everyone noticed there is nothing about
handling messages at all), but that is my guess as to the minimal
needed by a plugin.

== Plugin Autoupdater ==

A developer suggested that the plugin system should support automatic updates from plugin authors' sites. The primary reason given was the headache of supporting thousands of users who might seek help from the plugin author every time a Viewer update broke old plugins.

Soft Noel expressed concern that this would be a hard sell to LL as it makes the Viewer a potential vector for malware should plugin authors' update sites be hacked. On #opensl, Soft Noel suggested that, to head off anticipated LL liability concerns, a general purpose plugin updater could be written as a plugin and distributed with other plugins that used the updater.

== Two Source Releases ==

Rob Lanphier announced the release of the First Look 1.13.3.58390 source on Feb 24 and the 1.13.4.3 viewer beta on Feb 28:
https://wiki.secondlife.com/wiki/Source_downloads

Soft Noel noted build problems on the Mac, filing several bug reports and workarounds, however a texture bug continues to make 1.13.4.3 open source builds unusable on an Intel Mac. Others reported similar problems with the Linux build on SLDev and #opensl.

== Second Life viewer packaged for Fedora ==

Callum Lerwick announced an RPM-packaged viewer for Second Life, including library dependencies. He indicated that he had found another user doing duplicate work and suggested they had some merging to do. Packages are here:
http://www.haxxed.com/rpms/secondlife/

== Lip Sync and Gesture Motions ==

One plugin feature discussed was lip sync and gesture motions. Phoenix Linden wrote:
Just so everyone knows, we are already working on lip and gesture
motions for the avatar. This is no promise of functionality or
when it will be available, but it is in the pipeline and under
active development.

Later in the week, Mike Monkowski noted a C|Net article regarding Linden Lab's announcement of Vivox voice support:
http://news.com.com/Integrated+voice+coming+to+Second+Life/2100-1043_3-6162410.html?tag=nefd.top

== Stereoscopic Viewer ==

Eric Maslowski noted that the University of Michigan 3D lab was working on a stereoscopic 3D viewer:
http://um3d.dc.umich.edu/

Many of the questions in his announcement remained unanswered:
https://lists.secondlife.com/pipermail/sldev/2007-February/000612.html

== Agni, Aditi, and Uma ==

Dale Glass inquired about the grids available for Viewer developers. Joshua Bell replied, listing the three grids as Agni (live grid), Aditi (beta) and Uma (open source developers). Fuller details were included in Joshua Bell's response:
https://lists.secondlife.com/pipermail/sldev/2007-February/000618.html

== LSL Instantiated Prim Metadata ==

There has been a continuing discussion about the desirability of a custom data field that LSL could set on prims, and which Viewer developers could use for representing features not yet implemented on the server. Jason Giglio summarized the feature with an example use:
https://lists.secondlife.com/pipermail/sldev/2007-February/000644.html

The original Wiki proposal is here:
https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL

There was further discussion about whether an arbitrary named attribute system was desirable. In #opensl discussions it was noted that named parameters could already be set when communicating with the sim, but nobody voiced any guarantee that the data would persist, or suggested that this data could be set or directly accessed from LSL.

== LSL to Viewer Communications ==

Initially mentioned in the prior thread, Dale Glass mentioned a different system that allowed dynamic communication between a custom viewer and LSL. His details and a pointer to the Viewer source patch are laid out in his message:

https://lists.secondlife.com/pipermail/sldev/2007-February/000582.html

== Unit Testing Feedback Requested ==

Gaurav Sharma requested feedback on what parts of the viewer should be covered by unit testing. Rob Lanphier noted that Gaurav Sharma was working for Adroit, which had been hired for this task. John Hurliman suggested that the LLJoint class has been problematc, but there has been little other relevant feedback. Gaurav Sharma updated the patch with a second version later in the week. That version is here:
http://lists.secondlife.com/pipermail/sldev/attachments/20070302/d8809402/unittest-2-0001.obj

Gaurav Sharma's repeated request for unit test suggestions is here:
https://lists.secondlife.com/pipermail/sldev/2007-March/000695.html

== Linux Viewers and 3D Acceleration ==

Truxpin was having difficulty making Second Life run on his machine using open source nVidia drivers. David Fries states that Linden Lab currently requires a 24 bit depth buffer, while Mesa only supports 16 bit depth. David Fries (SpacedOut Frye) offered a patch that would request an OpenGL context with a 16 bit depth buffer if the 24 bit depth buffer request failed.

Truxpin posted an e-mail including glxinfo which showed,
direct rendering: No
server glx vendor string: SGI
Indicating he only had software OpenGL rendering available. The patch allowed the Second Life viewer to run with a 0.7 frame rate which also indicated software rendering.

Truxpin later posted (off list) that he was able to get the nVidia driver installed and running at about the same speed under Linux as Windows on that computer.

nVidia users currently require the closed source driver for 3D OpenGL acceleration.

== Linden Lab and Open Source ==

Christian Westbrook stated that Linden Lab had not yet completely accepted open source development. Rob Lanphier posted a response detailing the extent of Linden Lab's contributions and some of the remaining legal and business hurdles Linden Lab is working to move out of the way.

Rob Lanphier repeats emphasis on the necessity for list contributors to sign contributor agreements in order to free Linden Lab employees to more directly interact with SLDev members.

== Plugin Source Licensing ==

SLDev members inquired through the list and IRC channel about whether GPL must be used for the plugin system. Developers have concerns about whether non-free plugins can be developed without complex circumvention measures. Rob Lanphier indicated that the issue is being pressed internally.

== OpenJPEG patch (see VWR-123) still not merged ==

Soft Noel ran into the known buffer overflow in LLImageJ2COJ::decodeImpl() using source version beta-1.13.4.3 on Intel Mac. She disabled jpeg decoding to continue to make progress.
David Fries (SpacedOut Frye) (March 3rd) pointed out the fix in VWR-123 on jira, and again asked why it hasn't made it into the source code release.

SLDev-Traffic 1

2007-03-03T17:18:27Z

SpacedOut Frye: corrected and expanded entry

Build the Viewer on Linux

2007-02-27T04:32:20Z

SpacedOut Frye: OpenJPEG 1.1.1 update

{{CompileNav}}

The following are instructions for building the Second Life viewer on linux. This process has only been used on [http://www.debian.org/ debian] and debian based systems like [http://www.ubuntu.com/ ubuntu]. 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 dependancies (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.

=== 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''' and/or '''without''' 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 [package: g++-3.4]; 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:
*** Remove the reference to 'fmod-3.75' in indra/SConstruct
*** Replace '-DLL_SDL=1' with '-DLL_SDL=1 -DLL_FMOD=0' in indra/SConstruct
*** Comment-out the libfmod line in indra/newview/linux_tools/client-manifest-i686

* You will need the Curl library [package: libcurl-dev] - 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 [packages: mesa-common-dev, libglu1-mesa-dev, libx11-dev]

* You will need GTK 2.x development headers [libgtk2.0-dev]

* 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 [libboost-dev]
** boost-regex [libboost-regex-dev]
** apr-1 [libapr1.0-dev]
** aprutil-1 [libaprutil1.0-dev]
** 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]].
*** Build with ./configure --prefix=/usr --includedir=/usr/include/xmlrpc-epi --[[User:Caelum Lewellen|Caelum Lewellen]] 15:47, 11 January 2007 (PST)
** jpeglib [libjpeg62-dev]
** SDL [libsdl1.2-dev]
** Vorbis [libvorbis-dev]
** 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.
*** 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
** expat [libexpat1-dev]

=== 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.
* ${FMOD} refers to the top-level directory into which you unpacked FMOD 3.
<code>
cp ${FMOD}/api/inc/* ${SLSRC}/libraries/i686-linux/include/
cp ${FMOD}/api/libfmod-3.75.so ${SLSRC}/libraries/i686-linux/lib_release_client/

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/

</code>

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

== Compiling ==

<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release
</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 to follow the instructions in the '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
<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/linux_tools/client-manifest-i686 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.

==== "Unable to initialize communications" ====

If the viewer just displays the error message " Unable to initialize communications" and exits, it can't find message_template.msg. You did remember to copy it over, right?

=== 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/linux_tools/client-manifest-i686

==== Packaging errors ====

The final packaging step may fail with errors about the manifest if you are not using the slviewer-linux-libs bundle; in this case, if you still wish to end up with an end-user viewer package incorporating your own libraries, you can edit the manifest file found at indra/newview/linux_tools/client-manifest-i686

==== FreeBSD ====

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

Compiling the viewer (Mac OS X)

2007-02-27T04:32:16Z

SpacedOut Frye: OpenJPEG 1.1.1 update

{{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
$ 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.1.1 [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>

* 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

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

== CURL ==
* Make a sub-directory in lindenlib called curl; cd into it
* Download [http://curl.haxx.se/download.html libcurl]; untar; rename the expanded tree src-curl
* Download [http://daniel.haxx.se/projects/c-ares/ c-ares]; untar; rename the expanded tree src-c-ares
* Run the following commands (you may find it convenient to put this in a shell script file):
<pre>
#!/bin/sh

BUILD_C_ARES=$PWD/build-c-ares
BUILD_CURL=$PWD/build-curl

mkdir build-c-ares || true
mkdir build-curl || true

case `arch` in
(i386) export CFLAGS="-O2 -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk";;
(ppc) export CFLAGS="-O2 -g -isysroot /Developer/SDKs/MacOSX10.3.9.sdk";;
(*) echo "unknown architecture"; exit 1;;
esac

#export CFLAGS="$CFLAGS -arch i386 -arch ppc"
#export LDFLAGS="-arch i386 -arch ppc"
# this won't work until we abandon 10.3.9

cd src-c-ares
./configure --prefix=$BUILD_C_ARES --disable-dependency-tracking
make clean
make
make install
cd ..

cd src-curl
./configure --prefix=$BUILD_CURL \
--disable-dependency-tracking \
--disable-shared \
--enable-http \
--disable-ftp \
--disable-file \
--disable-ldap \
--disable-dict \
--disable-telnet \
--disable-tftp \
--disable-manual \
--disable-ipv6 \
--enable-nonblocking \
--enable-ares=$BUILD_C_ARES \
--enable-verbose \
--disable-cookies \
--without-libidn \
--with-ca-bundle=`curl-config --ca`
make clean
make
make install -k
# because you won't be able to overwrite the ca-bundle in your system

cd ..

cp $BUILD_C_ARES/lib/libcares.a .
cp $BUILD_CURL/lib/libcurl.a libllcurl.a
# note the name change

tar cvzf libs-curl-`arch`.tgz libcares.a libllcurl.a
</pre>
* This builds a tar file called libs-curl-<arch>.tgz, where <arch> is either i386 or ppc
* Expand this tar file into linden/libraries/<arch>-darwin/lib_release and linden/libraries/<arch>-darwin/lib_debug

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

Download the llmozlib source tarball and extract it (it doesn't need to be in any particular place relative to the linden tree)

Note: The llmozlib tarball is not currently linked from the main source download page. There's a link to it on the [http://secondlife.com/developers/opensource/wiki/Source_archive Source archive] page.

=== Build libxul from the mozilla source ===

If you have a multiprocessor machine, you may wish to enable parallel make for the mozilla build by adding the following line to llmozlib/build_mozilla/mac-universal-libxul-bits/mozconfig:

<pre>
mk_add_options MOZ_MAKE_FLAGS=-j4
</pre>

I use -j4 on a 4-core machine. Adjust to taste.

Run the shell script that checks out the mozilla source, applies a few patches, configures and builds:

<pre>
$ cd llmozlib/build_mozilla
$ ./mac-checkout_patch_build.sh
</pre>

You'll have to answer a CVS password prompt immediately after starting the script (use password "anonymous"), but the rest should complete without any intevention.

This will take some time. I usually go for a cup of coffee or a nice dinner.

If the build completes without errors, you've got the hard part done.

=== Copy headers and libraries needed to build llmozlib ===

<pre>
$ cd llmozlib
$ ./copy_products_mac.sh
</pre>

This copies certain of the headers and libraries created by the mozilla build into llmozlib/libraries. It also pulls the files needed by libxul at runtime into a .tgz file in the llmozlib directory.

After you've done this, you can safely delete the intermediate results created by step 1. These are:
<pre>
llmozlib/build_mozilla/mozilla/
llmozlib/build_mozilla/objdir-mozilla-universal/
llmozlib/build_mozilla/cvsco.log
</pre>

=== Build llmozlib ===

Open llmozlib/llmozlib.xcodeproj and build the "Release" configuration of the "llmozlib" target.

There's a problem which sometimes causes XCode to not be able to find some of the mozilla headers the first time you build after a clean checkout or download of llmozlib. Close the project, re-open it, and build again and it should work.

Alternately, if you'd rather stay on the command line, you can do:

<pre>
$ cd llmozlib
$ xcodebuild -project llmozlib.xcodeproj -target llmozlib -configuration Release build
</pre>

=== Copy build results into the linden tree ===

<pre>
$ cd llmozlib
$ ./repackage_runtime_mac.sh ../path/to/linden/
</pre>

This will copy the necessary libraries and runtime files to the linden source tree.

The argument to the script should be either a relative or absolute path to the root of the tree (i.e. the directory that contains 'indra').

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

Compiling the viewer (Mac OS X)

2007-02-16T05:02:16Z

SpacedOut Frye: OpenJPEG patch note and fixes

{{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
$ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386-darwin/lib_release
</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
$ 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>

* 02-15-2007, another set of patches is required to both OpenJPEG and Second Life to make it usable, that is fix a crash, make it look good, and speed it up. https://jira.secondlife.com:443/browse/VWR-123

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

== CURL ==
* Make a sub-directory in lindenlib called curl; cd into it
* Download [http://curl.haxx.se/download.html libcurl]; untar; rename the expanded tree src-curl
* Download [http://daniel.haxx.se/projects/c-ares/ c-ares]; untar; rename the expanded tree src-c-ares
* Run the following commands (you may find it convenient to put this in a shell script file):
<pre>
#!/bin/sh

BUILD_C_ARES=$PWD/build-c-ares
BUILD_CURL=$PWD/build-curl

mkdir build-c-ares || true
mkdir build-curl || true

case `arch` in
(i386) export CFLAGS="-O2 -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk";;
(ppc) export CFLAGS="-O2 -g -isysroot /Developer/SDKs/MacOSX10.3.9.sdk";;
(*) echo "unknown architecture"; exit 1;;
esac

#export CFLAGS="$CFLAGS -arch i386 -arch ppc"
#export LDFLAGS="-arch i386 -arch ppc"
# this won't work until we abandon 10.3.9

cd src-c-ares
./configure --prefix=$BUILD_C_ARES --disable-dependency-tracking
make clean
make
make install
cd ..

cd src-curl
./configure --prefix=$BUILD_CURL \
--disable-dependency-tracking \
--disable-shared \
--enable-http \
--disable-ftp \
--disable-file \
--disable-ldap \
--disable-dict \
--disable-telnet \
--disable-tftp \
--disable-manual \
--disable-ipv6 \
--enable-nonblocking \
--enable-ares=$BUILD_C_ARES \
--enable-verbose \
--disable-cookies \
--without-libidn \
--with-ca-bundle=`curl-config --ca`
make clean
make
make install -k
# because you won't be able to overwrite the ca-bundle in your system

cd ..

cp $BUILD_C_ARES/lib/libcares.a .
cp $BUILD_CURL/lib/libcurl.a libllcurl.a
# note the name change

tar cvzf libs-curl-`arch`.tgz libcares.a libllcurl.a
</pre>
* This builds a tar file called libs-curl-<arch>.tgz, where <arch> is either i386 or ppc
* Expand this tar file into linden/libraries/<arch>-darwin/lib_release and linden/libraries/<arch>-darwin/lib_debug

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

Download the llmozlib source tarball and extract it (it doesn't need to be in any particular place relative to the linden tree)

Note: The llmozlib tarball is not currently linked from the main source download page. There's a link to it on the [http://secondlife.com/developers/opensource/wiki/Source_archive Source archive] page.

=== Build libxul from the mozilla source ===

If you have a multiprocessor machine, you may wish to enable parallel make for the mozilla build by adding the following line to llmozlib/build_mozilla/mac-universal-libxul-bits/mozconfig:

<pre>
mk_add_options MOZ_MAKE_FLAGS=-j4
</pre>

I use -j4 on a 4-core machine. Adjust to taste.

Run the shell script that checks out the mozilla source, applies a few patches, configures and builds:

<pre>
$ cd llmozlib/build_mozilla
$ ./mac-checkout_patch_build.sh
</pre>

You'll have to answer a CVS password prompt immediately after starting the script (use password "anonymous"), but the rest should complete without any intevention.

This will take some time. I usually go for a cup of coffee or a nice dinner.

If the build completes without errors, you've got the hard part done.

=== Copy headers and libraries needed to build llmozlib ===

<pre>
$ cd llmozlib
$ ./copy_products_mac.sh
</pre>

This copies certain of the headers and libraries created by the mozilla build into llmozlib/libraries. It also pulls the files needed by libxul at runtime into a .tgz file in the llmozlib directory.

After you've done this, you can safely delete the intermediate results created by step 1. These are:
<pre>
llmozlib/build_mozilla/mozilla/
llmozlib/build_mozilla/objdir-mozilla-universal/
llmozlib/build_mozilla/cvsco.log
</pre>

=== Build llmozlib ===

Open llmozlib/llmozlib.xcodeproj and build the "Release" configuration of the "llmozlib" target.

There's a problem which sometimes causes XCode to not be able to find some of the mozilla headers the first time you build after a clean checkout or download of llmozlib. Close the project, re-open it, and build again and it should work.

Alternately, if you'd rather stay on the command line, you can do:

<pre>
$ cd llmozlib
$ xcodebuild -project llmozlib.xcodeproj -target llmozlib -configuration Release build
</pre>

=== Copy build results into the linden tree ===

<pre>
$ cd llmozlib
$ ./repackage_runtime_mac.sh ../path/to/linden/
</pre>

This will copy the necessary libraries and runtime files to the linden source tree.

The argument to the script should be either a relative or absolute path to the root of the tree (i.e. the directory that contains 'indra').

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

Build the Viewer on Linux

2007-02-16T04:52:18Z

SpacedOut Frye: Expand on OpenJPEG

{{CompileNav}}

The following are instructions for building the Second Life viewer on linux. This process has only been used on [http://www.debian.org/ debian] and debian based systems like [http://www.ubuntu.com/ ubuntu]. 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 dependancies (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.

=== Prerequisites ===

* You will need the SCons build tool [package: scons]
* You should use the GCC 3.4 C/C++ compiler [package: g++-3.4]; 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:
*** Remove the reference to 'fmod-3.75' in indra/SConstruct
*** Replace '-DLL_SDL=1' with '-DLL_SDL=1 -DLL_FMOD=0' in indra/SConstruct
*** Comment-out the libfmod line in indra/newview/linux_tools/client-manifest-i686

* You will need the Curl library [package: libcurl-dev] - 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 [packages: mesa-common-dev, libglu1-mesa-dev, libx11-dev]

* You will need GTK 2.x development headers [libgtk2.0-dev]

* 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 [libboost-dev]
** boost-regex [libboost-regex-dev]
** apr-1 [libapr1.0-dev]
** aprutil-1 [libaprutil1.0-dev]
** 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]].
*** Build with ./configure --prefix=/usr --includedir=/usr/include/xmlrpc-epi --[[User:Caelum Lewellen|Caelum Lewellen]] 15:47, 11 January 2007 (PST)
** jpeglib [libjpeg62-dev]
** SDL [libsdl1.2-dev]
** Vorbis [libvorbis-dev]
** 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 greater than 1.1 is required which hash the macro OPJ_PATH_LEN. Version 1.1 and before would crash with a divide by zero with Second Life. Get the source with svn until 1.2 comes out.
*** 02-15-2007, another set of patches is required to both OpenJPEG and Second Life to make it usable, that is fix a crash, make it look good, and speed it up. https://jira.secondlife.com:443/browse/VWR-123
** expat [libexpat1-dev]

=== 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.
* ${FMOD} refers to the top-level directory into which you unpacked FMOD 3.
<code>
cp ${FMOD}/api/inc/* ${SLSRC}/libraries/i686-linux/include/
cp ${FMOD}/api/libfmod-3.75.so ${SLSRC}/libraries/i686-linux/lib_release_client/

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/

</code>

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

== Compiling ==

<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release
</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 to follow the instructions in the '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
<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/linux_tools/client-manifest-i686 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.

==== "Unable to initialize communications" ====

If the viewer just displays the error message " Unable to initialize communications" and exits, it can't find message_template.msg. You did remember to copy it over, right?

=== 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/linux_tools/client-manifest-i686

==== Packaging errors ====

The final packaging step may fail with errors about the manifest if you are not using the slviewer-linux-libs bundle; in this case, if you still wish to end up with an end-user viewer package incorporating your own libraries, you can edit the manifest file found at indra/newview/linux_tools/client-manifest-i686

==== FreeBSD ====

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