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

Which seems pretty odd to me after all these years of "Unix standards" and so many GGC-using OSes needing to keep multiple GCC versions active.

Oh well.

Might be worth starting a separate wiki page for each platform-distro-version combination being used and start collecting specific hack-and-slash changes for that combination there?

Write once... patch everywhere... and I thought people said Java had that problem

It seems the "official" build support is for Debian and Ubuntu variants, but from the Linux forum posts in general it seems there are a few heretics willing to run Fedora. Maybe I will go insane temporarily and try installing the client on Solaris x86 or something else equally odd.

Client: 1.13.2.11
Source Tree: 20070117a
Used slviewer-linux-libs: No
Compiler: g++ 4.11
OS: Fedora Core 6

objcopy --keep-global-symbols newview/linux_tools/exposed-symbols.txt newview/secondlife-i686-bin-globalsyms newview/secondlife-i686-bin
objcopy: 'newview/linux_tools/exposed-symbols.txt': No such file
scons: *** [newview/secondlife-i686-bin] Error 1
scons: building terminated because of errors.

I don't see that file anywhere... even in the 20070112a distribution?

Thanks for pointing that out, it's something missing from the manifest. You can safely make an empty file with that name to continue.

So I got SL built with GCC 4.1.1 on x86_64(even with my CFLAGS set to -O2 -pipe -march=athlon64 -msse3).. I only needed to patch 3 files from latest release for GCC 4 compatability.. there were some c-style casts from (void *) to primitives. ewww!

--- ~/slunedited/linden/indra/newview/llfloatereditui.cpp	2007-01-20 04:26:41.000000000 +0000
+++ ~/slvanilla/linden/indra/newview/llfloatereditui.cpp	2007-01-20 06:03:21.000000000 +0000
@@ -53,7 +53,7 @@
 	for(idx = 0,itor = parentChildren->begin();itor!=parentChildren->end();itor++,idx++){
 		if((*itor)==view)break;
 	}
-	switch((int)data)
+	switch(*(static_cast<int *>(data)))
 	{
 		case	0	://up
 			view = view->getParent();

--- ~/slunedited/linden/indra/newview/lltexlayer.cpp	2007-01-20 04:26:43.000000000 +0000
+++ ~/slvanilla/linden/indra/newview/lltexlayer.cpp	2007-01-20 06:21:38.000000000 +0000
@@ -487,7 +487,7 @@
 // static
 void LLTexLayerSetBuffer::onTextureUploadComplete(const LLUUID& uuid, void* userdata, S32 result) // StoreAssetData callback (not fixed)
 {
-	LLBakedUploadData* baked_upload_data = (LLBakedUploadData*)(U32)userdata;
+	LLBakedUploadData* baked_upload_data = static_cast<LLBakedUploadData*>(userdata);
 
 	LLVOAvatar* avatar = gAgent.getAvatarObject();

--- ~/slunedited/linden/indra/newview/llviewermenu.cpp	2007-01-20 04:26:42.000000000 +0000
+++ ~/slvanilla/linden/indra/newview/llviewermenu.cpp	2007-01-20 06:35:00.000000000 +0000
@@ -5025,7 +5025,7 @@
 	LLFilePicker::ELoadFilter type;
 	if(data)
 	{
-		type = (LLFilePicker::ELoadFilter)((S32)data);
+		type = (LLFilePicker::ELoadFilter) (*static_cast<S32 *>(data));
 	}
 	else
 	{
@@ -5930,7 +5930,7 @@
 
 BOOL menu_check_build_tool( void* user_data )
 {
-	S32 index = (S32) user_data;
+	S32 index = *static_cast<S32 *>(user_data);
 	return gCurrentToolset->isToolSelected( index );
 }
 
@@ -8075,7 +8075,7 @@
 
 void handle_grab_texture(void* data)
 {
-	LLVOAvatar::ETextureIndex index = (LLVOAvatar::ETextureIndex) ((U32) data);
+	LLVOAvatar::ETextureIndex index = (LLVOAvatar::ETextureIndex) (*static_cast<U32 *>(data));
 	LLVOAvatar* avatar = gAgent.getAvatarObject();
 	if ( avatar )
 	{
@@ -8166,7 +8166,7 @@
 
 BOOL enable_grab_texture(void* data)
 {
-	LLVOAvatar::ETextureIndex index = (LLVOAvatar::ETextureIndex) ((U32) data);
+	LLVOAvatar::ETextureIndex index = (LLVOAvatar::ETextureIndex) (*static_cast<U32 *>(data));
 	LLVOAvatar* avatar = gAgent.getAvatarObject();
 	if ( avatar )
 	{

I know it's not a very pretty solution.. but void pointers aren't very clean in the first place.
For those building x86_64, make a copy of newview/linux_tools/client_manifest_i686 and name it client_manifest_x86_64. Do a find and replace all instances of i686 with x86_64. You may also need to either copy the libs listed in the manifest into libraries/x86_64/lib_client_release, or change the paths in the manifest to your /usr/lib dir. Also you'll have to edit SConstruct and change gcc_bin to point to your local copy of g++(NOT GCC), and do the same for strip. I haven't been able to actually run the client yet, I'm recompiling because there was a stray pointer in xmlrpc's latest CVS. Good luck everybody!

Edit:..okay and the resulting binary is a nogo.. glibc detected: free() invalid next size (fast) right off the bat. So maybe my initial enthusiasm was uncalled for. bleh. I'll poke around some more.

I don't know what to do with a linux "software" like SecondLife after I have uncompress it. I have configure the firewall to open at specefic ports like mentionned in SL. Thank you for any help

Managed to build the client from the opensecondlife project's subversion repository on Linux. It looked a bit 'I see grey people' but no crashes so hopefully this information will be helpful to people anticipating (dreading) the next major upgrade. I used the orginal linux distro SConstruct (so at best you will need to download it the once) and the latest svn builds a version 2(11) client.

Follow the instructions on the site to build the source tree, the rest of the info is oriented towards people building using MS Visual Studio. I would be interested if people think there might be, for example CRLF (ick!), issues lurking.

Amber

Its the difference between playable, and completely unusable. This means a completely free software client (Eligible for inclusion in Fedora!) is currently crippled and unplayable.

It appears that jpeg2k decode is done in a blocking manner, slowing the whole client to an unusable crawl. If you sit in a quiet place and wait until all the textures load, it will become usable again.

People have been begging for a multiprocessor-friendly SL client, dedicating a thread to nonblocking texture decompression would probably be a good start...

Read the README-linux.txt file in the SecondLife_i686* directory.

Your graphic controller should support OpenGL in the driver.

Or you can just try and run ./secondlife in the SecondLife_i686* directory.

Hope you will get it to work.

The most enjoyable greetings
Agerskov Clave aka Claus Agerskov in First Live
http://www.agercon.dk/

Yay!! So I finally got it compiled and running on Linux x86_64!

..only to be faced with the horrors of openjpeg.. yeah, we really do need to come up with an asynchronus J2k codec. (Has anybody looked at Jasper? The author was the the first to implement a J2K decoder, but I dunno if it's any good.)

one other thing I noticed, my console is FLOODING with "[error] tcd_decode: incomplete bitstream" any ideas? Is this just standard, or might it have something to do with the slowness we're experiencing, I.E. the open source client is dropping texture packets or something along those lines.. just a thought.

otherwise, great work SL devs! And thank you thank you thank you for open sourceing this!

From the testing I've done, JasPer is a little quicker than OpenJPEG, but not the orders of magnitude quicker that Kakadu is.

There's not really any such thing as an asynchronous codec, it's up to the calling application to call it asynchronously and handle the threading or whatever. Given that Kakadu is so much quicker while still being called synchronously, I believe there is plenty of scope for optimisation, both algorithmically and by using SIMD instructions.

Kakadu is much quicker, but it also supports a 'decode as much as you can in X milliseconds' mode which helps responsiveness, which OpenJPEG doesn't.

When Firstlook gets merged to trunk, OpenJPEG decoding will transparently happen on another thread, which certainly helps cure its general framerate-killing.