The 'building the open source linux client' help thread!

While we've put a lot of work into making this compile at all I don't expect it to be a particularly easy build.

So! Here's a thread where we can help each other, until a more appropriate forum comes into being!

p.s. I'm going to be monitoring the forum (and the Linux Client Users in-world group) for most of the day to seed some knowledge to get people started.

My first tip is to grab our pre-built bundle of libraries when you grab the source - it removes a lot of complication for when you're getting your first build done.

Tofu, you're an absolute star!

I wonder if I can convince my build environment to run in 32 bit mode This will be a thrill ride I guess this will be the perfect reason for me to start a blog.

I'd recommend anyone to start with a (relatively) easy build, which is to say 32-bit x86 Linux with our precompiled library package.

Now, assuming you want a 64-bit native build... instructions are provided on the wiki linux build page for slotting-in all of the third-party libs native to your distro/arch, and I've done a few builds like this (for x86), though it's fiddly! We had a 64-bit Linux client working internally some months back, and (I believe) our Mac target requires 64-bit cleanliness so hopefully 64-bit is not intrinsically a problem. You'll probably have to do without audio and KDU support though, which means the resulting client will be quiet and relatively slow to decode textures.

Let us know how you get on!

I get through a few minutes of compiling and it terminates with this error:

/tmp/tim/home/tim/Desktop/linden/indra/i686-linux-client-release/llwindow/llwindowsdl.cpp:44:22: gtk/gtk.h: No such file or directory
/tmp/tim/home/tim/Desktop/linden/indra/i686-linux-client-release/llwindow/llwindowsdl.cpp: In function `BOOL maybe_do_gtk_diagnostics()':

I've installed the debian packages libgtk2.0-dev libgtk1.2-dev so I'm not sure what to do now.

I followed the Compiling the Viewer instructions for building the standard linux binary, I disabled the FMOD option. This is on a Debian 'sid' install.

I've also hit a snag:

scons: *** [/tmp/XXX/home/XXX/Desktop/slviewer-src/indra/i686-linux-client-release/llrender/llimagegl.o] Error 1
/tmp/XXX/home/XXX/Desktop/slviewer-src/indra/i686-linux-client-release/llwindow/llgl.cpp: In static member function `static void LLGLState::checkTextureChannels()':
/tmp/XXX/home/XXX/Desktop/slviewer-src/indra/i686-linux-client-release/llwindow/llgl.cpp:1069: error: `glActiveTextureARB' was not declared in this scope

I grepped my includes dir and found that gl.h, glext.h, and gl_mangle.h all reference "glActiveTextureARB", so I copied them one by one into {SLVIEWER}/libraries/includes/GL, with no effect.

Any ideas? I'm still fiddling with it, but any guidance is welcome!

I'm on FC6 - using the compat-gcc-34-c++ compiler package. I'm also using the provided libraries from SL.

Thanks!
Paco

Hi there! Thanks for the feedback.
I'm collecting common errors and posting probably solutions to https://wiki.secondlife.com/wiki/Common_compilation_problems#Linux

Both of these errors should find solutions there, I hope.

Even though I have mesa GL installed, Nvidia's driver had overwritten the GL header files.

I used this method (on FC6):
rpm -ev --nodeps mesa-libGL-devel
yum install mesa-libGL-devel

Also, the binary name for gcc++ 3.4 in FC is slightly different:
Around line 208, replace "gcc_bin = 'g++-3.4'" with "gcc_bin = 'g++34'"

It's happily compiling now

HTH,
Chris

Running the compiled client "in-tree" (per the wiki) is non-useable. I show extreme packet loss according to the meter, and the sim is still only 10-15% rezzed after about 5 min.

Compiling with 'BUILD=releasefordownload' provides a much smoother experience. After uncommenting the lines in the manifest file that pertain to libllkdu.so and libkdu_v42R.so, and also commenting the line for unicode.ttf (archive fails otherwise), I've only come across one issue so far - my avatar is extremely fuzzy or low-res. Others in SL confirm that the avatar appear low-res to them also. Editing appearance clears it up (mostly), but as soon as the appearance editor is closed (save or not), the avatar returns to the low-res state. Relogging with the provided alpha client returns the avatar to normal. I wonder if this is related to the jpeg2000 libraries somehow?

Hate to hog the thread - just thought I should report results/issues here.

Chris AKA Paco

It works!

Post Reply in this thread looks partially broken for me, I put the whole stuff with some details here:
http://signore.wordpress.com/2007/01/08/compiling-the-second-life-viewer-source-code-on-ubuntu-edgy/

Woo, got it working :)

I had to make a few alterations to the source to get it stable, though. In particular, I found a double-free bug in LLFont's destructor which could appear if a font load failed - I've reported this using the bug report option in-game, along with the patch here: http://www.fushizen.net/sl-fontface-doublefree.patch. This issue is most likely made visible because I used gcc 4.1.1 to build (and it took quite a lot of header modifications to do so, but it worked in the end...), which may have altered the heap layout in some way.

Also, LLDrawPool::createPool can't handle POOL_MEDIA, which causes a crash when LLPipeline::getPoolFromTE requests such a pool. Since I didn't see any obvious implementation of LLDrawPoolMedia, I stubbed it out like so:

--- linden_pristine/linden/indra/newview/pipeline.cpp   2007-01-07 17:50:25.000000000 -0500
+++ linden/indra/newview/pipeline.cpp   2007-01-09 02:22:16.000000000 -0500
@@ -1548,7 +1548,7 @@
                alpha = alpha || (imagep->getComponents() == 4) || (imagep->getComponents() == 2);
        }

-       if (te->getMediaFlags() == LLTextureEntry::MF_WEB_PAGE)
+       if (0 && te->getMediaFlags() == LLTextureEntry::MF_WEB_PAGE)
        {
                return gPipeline.getPool(LLDrawPool::POOL_MEDIA, imagep);
        }

I have no idea if that is truly safe.

These issues may or may not be exacerbated by my choice to build using gcc 4.1 (I'll post up some patches to the headers tomorrow if I get around to it) on a 64-bit host, with a 32-bit target - but hey, it seems to work, after a fashion :)

Edit: Actually, maybe I'll just edit them out now. Here are the patches I'm using, minus some 64-bit-related sconstruct hacks that aren't really worth releasing: http://www.fushizen.net/sl-patches/

Hi!
Something that the wiki might not make clear is that the code-drops are usually from the development 'trunk', which is to say that it may contain a smattering of bugs and a pile of fixes/features not in any currently-released binary version of the client. The fuzzy-avatar thing is one of the things from trunk at the time which, um, isn't a fix/feature.

Thanks everyone for the feedback, keep it coming - I'll be addressing a bunch of the common Linux build problems (particularly versus GCC 4.x) and the fixes should be in one of the near-future code-drops.

Finally got it going, but it dies immediately after trying to display the world for the first time. Disabling all of the OpenGL extensions in the secondlife script got me in world, but I still only lasted for a minute or two.

Bah, going to leave it for now until after tomorrows update, I can't really justify spending any more time on it knowing I have to do it again tomorrow.

Just to clarify, will future binary releases include a corresponding source snapshot as well?

That's the aim, though as it's currently a manual process (not to mention that release days are hectic) there may be some drift - there will soon be a test grid which always corresponds to the latest opensource release for continued testing.

Just a quick note to say that the wiki build instructions for the 20070112a source worked for me on Fedora 6 with NVidia's 1.0-9746 driver and g++ 3.4.

I opted not to use the slviewer-linux-libs set or try to tackle GCC4 on my first try with this source tree.

On my FC6 box, I did have to:
* patch SConstruct to read gcc_bin = 'g++34' (why did they change this in FC?)
* put the mesa GL headers into a libraries/i686-linux/include/GL directory in the slviewer source tree
* put the static*db2 files from the slviewer-linux-libs file into the runtime tree
* hack lines out of the manifest file to build the release package

Other than those stumbling points, building all of the dependencies and then the slviewer itself went as described on the wiki build and 'common compile errors' pages.

While compiling I did see a LOT of messages like "comparing signed and unsigned int" and "no ending newline on file blahblahblah". My next build I will try to capture these and report them in.

My first startup crashed immediately, until I linked unicode.ttf to something... I used /usr/share/fonts/japanese/TrueType/sazanami-mincho.ttf

Then I was able to get it to work, login, move around, hear sound, and eventually see textures and such.

The speed difference in textures between the Linden-distributed client and the OpenJPEG-based client is pretty drastic... like a couple of orders of magnitude.

And of course, eventually, my compile crashes out and some random point, and the last message is a tile decode, which makes me think its OpenJPEG.

One time the error was 'over 400 messages queued on a frame.'

While running, I see tons and tons of read errors and incomplete texture notices, so I think OpenJPEG tries to read and make sense of textures and occasionally implodes from some texture coming down the pipe.

Maybe this weekend I can blow up my build tree and try again and make a complete log of the steps and results.

I just wanted to try it today to see if I could even get it to work, and I would call that a success.

So, I can't leave well enough alone.
Since I have a mostly working slviewer build... now the tinkering begins to make it run sans crashy.

OpenJPEG was my first target, since thats where I suspect my crashiness is coming from.

First, for reasons known only to me, I had installed the static lib libopenjpeg.a.
Rebuilt the source, and switched libopenjpeg.a out for libopenjpeg-1.0.0.so in the slviewer tree. Compiling OpenJPEG also got me two nitpicky warnings about tokens after endifs on like 1588 of j2k.c and line 264 of openjpeg.c... shouldn't make any difference, but I hacked the extra tokens out of mine.

While switching that, I realized I had done the same thing with libelfio... I built and installed a static version rather than dynamic.

So, I ran into the ELFIO tree again, cleaned out what had gone before... and can't seem to get ELFIO 1.0.3 to build anything BUT libELFIO.a.

The wiki build docs at https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 show that we should be copying the ELFIO dynamic lib (.so) into the slviewer tree... not the static.

Tofu, is 1.0.3 the version of ELFIO that you are using? If so, how are you compiling it to get the shared object rather than the static lib?

I must have made the dynamic version of ELFIO manually. I've updated the wiki with a simple recipe for doing that.

You can avoid OpenJPEG at runtime by plugging-in libkdu/libllkdu as the page directs, if interested.

Which wiki page? Unless I am just missing it, I don't see it on the Linux build or common compile pages.



FMOD and KDU are the two closed source bits right?
I would prefer to avoid those if possible.

The OpenJPEG seems to be slow when first downloading and processing the textures off of the server stream ... but once they are cached they are okay? That means that if you are patient, and don't move around all over the place, then OpenJPEG works for now. I tend to light in one place and chat for long times anyway, so we'll see.

https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29#Prerequisites

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

Thanks much Tofu... will try that next.

Also, as a test I tried the KDU libs... which cause an instant glibc free() crash and stack dump when starting the viewer. I will mess with this later, or in the next full rebuild.

Edit: bwahahaha - maybe it had something to do with the -DLL_USE_KDU=0 that is in the compile time options. I crack me up.

So theres no way around the texture corruption and KDU trying to delete and rebuild the texture nonstop?

-Asriazh

"They" didn't because there's absolutely no standard for this. (Having multiple gcc versions installed, that is.)