New Linux enhanced viewer: The Cool SL Viewer

Hmm... I thought that file was unmodified , but anyway I just erased it and grabbed the one at your website

Next failure was to not compile as root DUH!

It seems like I have a few unmet dependancies (in this case not installed things needed) that I have to track down, but at least it looks like it can be something in the end.

I'll get back with either questions about things not working (oh no ) or a result (positive or negative) about how it works on the 'puter that doesn't like the readymade versions.

Seems like another learning experience *giggles*, thanks for the help this far.

Time for another ranting update as promised way back in the discussion.

Today I finally got the code compiled and guess what? The same fault as with the precompiled ones *sighs* And I used the correct versions of everything and Henri's make-SL script unmodded.

I have played around a bit with the optimisation parameters as well without luck.

So next step some other day will be compiling a standard unpatched LL version and see if that one works I guess? (Hints are welcome, it would be fun nailing down wtf is wrong with my computer. I'll give it a shot with a bootable CD from another distro later to confirm that it is something with what is on the hard drive too.)

And LL's premade viewer as well as Loomi's RLV works well on the system so I understand absolutely nothing at all at the moment.

I wonder if anyone can help me with this.

There was a bug in the 1.20 Release Candidate, discussed at https://jira.secondlife.com/browse/VWR-7510 and elsewhere, that meant that if you muted a spammer in a group chat and he stayed there, the next time you said something, it unmuted him.

Dari Caldwell's comments at the end of that thread suggest it's fixed, or it was in RC 14.

It's certainly back, however, in Cool SL Viewer v1.20.15.0 -- I muted a spammer in Builders Exchange a day or so ago and, when five minutes later I replied to something someone else had said, I got a message telling me I'd unmuted the spammer. I'm not sure if this is a problem with RC15.0 or the Cool Viewer or a Windows vs Linux issue (OpenSuse 10.3, me). Anyone know?

To get the equivalent to LL's builds, just remove all the options from the TUNE_FLAGS variable (i.e. TUNE_FLAGS="" and set FORCE_VECTORIZE to "no".


I am certainly interested in your findings, so please keep us posted.

If this bug is present in the Cool SL Viewer v1.20.15.0 then it should also be present in the official Linden build of v1.20.15... Did you try it ?

Anyway, none of the patches used in the Cool SL Viewer would touch the muting mechanism.

Hmmm... I did so, no luck

I'll try doing an unpatched make as well *sighs*

Can anyone hint me how to debug this btw? I'm starting to wonder if there can be some kind of library screwed up on my computer or something, but how to find out ?

I mean, if the LL precompiled one and Loomi's RLV likewise precompiled one works, why can't compiling a cool viewer with the same build options by myself work? I don't get it *scratches the head*

Not giving up yet though, and I'll get back with any new findings!

No, I didn't.. that's why I asked here, in the hope that someone would know, thus saving me the bother of installing the official build and setting up an experiment. Looks like that's what I will have to do, though.

To debug the viewer, first make sure that "gdb" (the GNU debugger) is installed on your system, uncomment the "export LL_WRAPPER='gdb --args'" line in the "secondlife" script, then launch the said script from a terminal window (xterm, rxvt, gnome-terminal, etc...). gdb will start, load the viewer and wait for a command: type "run" to start the viewer.
When the viewer crashes, you may type "backtrace" to get a list of the functions which were last called. This usually gives good clues about which library or function is the culprit.
You might also want to run the unstripped binary of the viewer as it includes the symbols (function and variable names) used in the sources of the viewer, which will be printed by gdb: you can find this binary as /usr/src/SL/indra/newview/secondlife-i686-bin-globalsyms after compiling the Cool SL Viewer (just copy the unstripped binary over bin/do-not-directly-run-secondlife-bin).

For more help, please see the gdb manual...

Thanks Henri.
I have run that as you said on the latest compile that I did. (It's fyi a cool patched version compiled with the LL settings for optimisation if that matters)

Here is the output, and as that doesn't tell me much, can you give a clue on where to go as next step? I'd like to nail it down too, even though I'm not much of a programmer

(gdb) run
Starting program: /home/jessica/SL_test/bin/do-not-directly-run-secondlife-bin --settings test_settings.xml
[Thread debugging using libthread_db enabled]
[New Thread -1270860064 (LWP 5396)]
warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 000000b4
[New Thread -1271632976 (LWP 5402)]
2008-08-01T10:00:18Z INFO: (anonymous namespace)::LogControlFile::loadFile: logging reconfigured from /home/jessica/SL_test/app_settings/logcontrol.xml
2008-08-01T10:00:18Z INFO: initConfiguration: Loading settings file list/home/jessica/SL_test/app_settings/settings_files.xml

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1270860064 (LWP 5396)]
0x0a62576c in void boost::function2<bool, boost:ignals::detail:tored_group, boost:ignals::detail:tored_group, std::allocator<boost::function_base> >::assign_to<boost:ignals::detail::group_bridge_compare<std::less<int>, int> >boost:ignals::detail::group_bridge_compare<std::less<int>, int>:tored_vtable ()
(gdb) backtrace
#0 0x0a62576c in void boost::function2<bool, boost:ignals::detail:tored_group, boost:ignals::detail:tored_group, std::allocator<boost::function_base> >::assign_to<boost:ignals::detail::group_bridge_compare<std::less<int>, int> >boost:ignals::detail::group_bridge_compare<std::less<int>, int>:tored_vtable ()
#1 0xb7a74e0b in boost:ignals::detail::named_slot_map::named_slot_map ()
from /usr/lib/libboost_signals-gcc-mt-1_33_1.so.1.33.1
#2 0xb7a77ff5 in boost:ignals::detail:ignal_base_impl:ignal_base_impl ()
from /usr/lib/libboost_signals-gcc-mt-1_33_1.so.1.33.1
#3 0xb7a780e8 in boost:ignals::detail:ignal_base:ignal_base ()
from /usr/lib/libboost_signals-gcc-mt-1_33_1.so.1.33.1
#4 0x09b5bbc6 in LLControlVariable (this=0xaaf8570, name=@0xbfaa5df8, type=TYPE_LLSD, initial=@0xbfaa5c5c,
comment=@0xbfaa5e14, persist=false) at /usr/src/SL/libraries/include/boost/signals/signal_template.hpp:197
#5 0x09b63b62 in LLControlGroup::declareControl (this=0xbfaa60ac, name=@0xbfaa5df8, type=TYPE_LLSD,
initial_val=@0xbfaa5e1c, comment=@0xbfaa5e14, persist=0)
at /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/llxml/llcontrol.cpp:308
#6 0x09b67234 in LLControlGroup::loadFromFile (this=0xbfaa60ac, filename=@0xbfaa619c, set_default_values=false)
at /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/llxml/llcontrol.cpp:1097
#7 0x080e7576 in LLAppViewer::initConfiguration (this=0xaae7770)
at /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llappviewer.cpp:1563
#8 0x080eb3d0 in LLAppViewer::init (this=0xaae7770)
at /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llappviewer.cpp:633
#9 0x080f1a01 in LLAppViewerLinux::init (this=0xaae7770)
at /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llappviewerlinux.cpp:321
#10 0x080f2c94 in main (argc=162957488, argv=0x9b68780)
at /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llappviewerlinux.cpp:100
(gdb)

Apparently, your problem comes from libboost... Try uninstalling it from your system, then recompile the viewer (the linker apparently linked against the system dynamic libraries instead of LL's provided static libraries).

No luck there... The code doesn't compile without libboost-program-options, libboost-regexp and libboost-signals installed. The compiler just exits complaining over not finding them else.

Example:
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
scons: *** [newview/secondlife-i686-bin-globalsyms] Error 1
scons: building terminated because of errors.

Any other ideas to try?

OK Finally some good news!

I have (duh) read the tread back and seen that there's an issue with libboost indeed and that the make-SL needs a slight mod for the 1.20 branch for that.

And...

Removing all libboost packages completely from the machine, and edit the make-SL libboost patch to make sure the LL libboost files are used (and compile with LL's umoptimized settings) has actually made a usable viewer

So point #1 is that the stable debian's libboost are too old for compiling SL.

Now I'll try compiling again with the optimizations as well and see if there's any issue with the compiler options too.

Still there isn't a good explanation on why the precompiled version from Henri doesn't work, but at least we're on the track of something here.

I'll get back

It is indeed confirmed now that it is libboost that is the troublemaker on debian stable when it comes to compiling the viewer.

At the moment I'm running a cool viewer compiled with all the SSE stuff and other optimisations. All fine it seems at a quick test (like logging in )

Now, why isn't the precompiled version from Henri behaving? That one still gives segfaults (as usual on this machine/install)

Any ideas Henri? Some kind of version conflict or dependancy unmet?

At least we're one step closer as it's possible to compile a working one even on a naughty system

(There is one thing that seems a little strange, that might be an issue... the pointer doesn't change shape at the moment when f.ex. zooming with alt, is that something known?)
(The pointer issue was due to a missing directory... Hmmm... copied the "res-sdl" from the LL release and all is fine with the pointers)

You could try and use gdb with the pre-compiled version, to see if there is some other problem than libboost's, as indeed, the Cool SL Viewer is statically linked with libboost (the version used by LL)...


Yes, there are issues with the SConstruct file and/or the artwork archive (I didn't check these as the building system is going to switch to cmake real soon now) and it fails to copy some important files into the packaged viewer: you will want to copy the app_settings/shaders and res-sdl directories from an official build tree into your custom build installation directory, as the first is missing some shaders in customs builds, and the second is simply missing altogether... That's one of the reasons (with copyright related ones) why I distribute the Cool SL Viewer as a diff-files package instead of a full package...

That didn't gave much unfortunately.

GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run
Starting program: /home/jessica/SL_test/bin/do-not-directly-run-secondlife-bin --settings test_settings.xml
(no debugging symbols found)

Program received signal SIGFPE, Arithmetic exception.
0xb7f6b745 in ?? ()

I assume that the bin with the debug symbols are build specific, right?
So if you could give a copy of that file I could try debugging the build. I have used SecondLife_i686_1_20_15_0_CoolRelease_3-diff_files.tar.bz2 if you need to match the build version.



OK, I read somewhere on the LL pages that there are many changes happening, so thanks for some info there. And understandable that you use diffs. It's less to download too

No, but the debug symbols are stripped from the release version, as else, the binary would be 240Mb big, instead of 44Mb...

Here it is: http://rapidshare.com/files/134547590/CoolSLViewer_1.20.15.0_binary_with_symbols.tar.bz2.html

Got it, but to what use

(gdb) run
Starting program: /home/jessica/SL_test/bin/do-not-directly-run-secondlife-bin --settings test_settings.xml

Program received signal SIGFPE, Arithmetic exception.
0xb7f6c745 in ?? ()
(gdb) backtrace
#0 0xb7f6c745 in ?? ()
#1 0xb7f7aff4 in ?? ()
#2 0x08052f5a in ?? ()
#3 0xbfee70e8 in ?? ()
#4 0x00000001 in ?? ()
#5 0x06c9ec63 in ?? ()
#6 0xb5162f80 in ?? ()
#7 0xb7f7aff4 in ?? ()
#8 0x0000003e in ?? ()
#9 0xbfee6fc0 in ?? ()
#10 0xbfee6fd4 in ?? ()
#11 0xb7f6cb07 in ?? ()
#12 0xbfee6fc0 in ?? ()
#13 0xb7f7b650 in ?? ()
#14 0x00000000 in ?? ()
(gdb)


ANY ideas on where to look now?

(Is there a way to see what local libraries the SL-viewer uses or somthing?)

Are you sure you actually replaced the /home/jessica/SL_test/bin/do-not-directly-run-secondlife-bin file with the one you donwloaded ?

200% sure. (Doublechecked!) It's the 236115K big file that is there.
It's getting mysterious it seems.

I would like to see these features added to this great version These options could be added to the Cool Preferences.

1. Hide groups from showing in the Communicate window (above friends)

2. Show/Hide Gestures box

Apart from that its fantastic keep up the great work

I'm afraid I'm short of ideas, now... Oh, yes, just one last question: you are not running it in a 64bits environment, do you ?

Apart from that, I don't see what I could do without access to your system...

No, it's a standard plain 32 bit system. Nothing fancy, not even a homemade kernel.

My guess is that there is some stupid library that has the wrong version or something, but how to find that?
(And well, Debian stable is known for not having the latest versions so can that be an issue perhaps?)

What is good is that the cool viewer that I finally managed to compile is working well.

Still it's strange. Do you have any idea what the viewer wants installed on the system to run (besides a graphic environment) ?

Perhaps we can't get closer at the moment, but if I find anything I'll let you know of course.
I'm also out of ideas at the moment though...

Try (on a single line):

LD_LIBRARY_PATH=/path_to_viewer_directory/lib:/path_to_viewer_directory/app_settings/mozilla-runtime-linux-i686 ldd /path_to_viewer_directory/bin/do-not-directly-run-secondlife-bin

It will give you the list of all the dynamic libraries used by the viewer.

Re clean patch: There is *nothing* to patch - it is a drop-in replacement for a Windows library on Linux. The only patching needs to be done in the build system and a single define. Both diffs are on JIRA.

Re tweaking of a system: Nothing related to the code, however one needs to ensure access permissions to the device file in /dev/input. Unfortunately, there is no uniform way how to do this across distros (udev & hal rules, PolicyKit, PAM - each distro is different ...). If your distro gives access to those files by default, there is nothing to tweak.



That is a sound principle. Somebody buy him the SpaceNavigator if you want the support (-;

So there are indeed files to patch. What I call a "clean patch" is an unified diff file containing all the necessary changes to the sources. To produce a clean patch, proceed as follow:
1.- Extract the official viewer sources: it will produce a "linden" directory. We will use it as the reference sources and will let the files in them untouched.
2..- Copy this directory into another, that we will use for the patched files. Example:
cp -a linden linden-patched
("linden-patched" is just an example name, of course).
3.- patch all the files, add or remove files in linden-patched. For your patch, you will have to add the new library file (ndofdev.c) in the source tree, to modify SConstruct so that this library gets properly compiled and linked (you gave separate instructions on how to modify SConstruct to link it, so you did half of the work already), to modify llviewerjoystick.h, and to add a readme file (see below) for how to enable the joystick (also adding this file in the manifest so that it will be added to the final, packaged viewer).
4.- Produce the diff, in our example: diff -urN linden linden-patched >my_wonderful.patch
5.- Publish "my_wonderful.patch" on the JIRA


In this case, you should at the very least provide a readme file for the end user, explaining how they can obtain the proper result on their system: you cannot expect them to look on the JIRA in order to learn how to configure their system, especially as they will not even know whether or where to look on the JIRA in the first place. Also keep in mind that not all Linux users are geeks (actually, non-geeks users are what modern distros are aiming to, and that's a Good Thing(TM), if we want Linux to take a larger place in the OS landscape ;-P).