Self made viewer

Hi all,

Yesterday I compiled my own viewer following the easy and exhaustive instructions on the wiki. I must say it's very satisfactory, not to mention it seem a lot quicker, or at least more responsive, sleekier, and - without the mozlib extension - the memory footprint is smaller.

I solved most problems related to compiling the client, but I have one last problem: why the client has no audio.

I linked it against my own alsa libs, and I use the same flags I use for the standard client.

Who already compiled his/her own viewer? Who ran into this problem? More importantly, who solved it or can provide me good pointers?

Thank you all.

That way we can try and reproduce your problem...

The v1.17.2.0 viewer seems to have a problem when compiled as OPENSOURCE. I didn't succeed either in producing a version with functional audio, while all the viewer versions I compiled so far (till and including v1.17.0.12) are working just fine in this respect...

I tried pretty much all the combinations, including compiling and linking with -all- the LL provided libraries, to no avail.

I suspect there is a problem in the newest SConstruct file, but so far I could not spot it. My make-SL script yet already works around one problem (when compiled as OPENSOURCE some of the built-in viewer libraries are compiled as shared libraries but are not packaged, resulting in a non-functional viewer: make-SL works around this by patching the SConstruct file).

Henri.

@Thor: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.2.0

@Henri: you comforted me a bit. Isn't a specific problem with something I did/I didn't/I did wrong, then.

At the moment, I compile everything with my own system libraries, but Google Perftools (because that's not in Gentoo's portage), and disable the mozlib, which I consider a huge, useless memory sink.

I use make-SL, too, but I had to fix it in a couple of places:

1) When it checks for APR:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
Since I have TWO installed APRs (portage slotted), the "-f" check fails, because it receives TWO arguments, and expects one.

2) The (required!) libs created in
$PATH_TO_SOURCES/indra/lib_releasefordownload_client/i686-linux
are NOT copied in the final tar.bz2 package. I had to manually add a trivial tar command in the compile function to fix it.

I'll try and help you scanning the SConstruct (pythonesque Makefile?), to see if something goes wrong with the audio part. Actually, besides the FMOD crap, I don't see why the viewer shouldn't use the alsa (or oss emulated by alsa) devices.

Maybe it's the FMOD: possibly the one referenced by the wiki is old, and not working anymore with 17.2?

Err... Why do you have two apr devel packages installed ? o.o I can understand that there are two (or more) apr libraries installed on a system, but you should only have one set of header files: the one you need to compile against the latest apr version... The wildcard is needed here, as I can't know in advance which version of apr is intalled on the systems make-SL is ran under...



Which libraries did not get packaged ?.... They get all packaged ok here...



No, I also explored this possibility, but the vesrion released by LL still has fmod v3.75 libraries packaged in it, and this version does work fine as far as sound is concerned... I see only one other possibility, aside from a broken SConstruct file: the sources LL made available are in fact not the sources they used to build v1.17.2.0. This won't be the first time they release incomplete or bad sources (v1.17.1.0 sources are missing all the PNG related files, for example, making them impossible to compile without a lot of patching)...

If anyone from LL reading this could please investigate, it would be great... I'd hate to see a next, mandatory version released without proper sources (I must rely on personal patches in order to be able to run the viewer on one of my systems: see the "infamous ATI bug" thread on this forum)...

I'm currently running a self-compiled v1.17.0.12, but v1.18 will be another story...

Henri.

I have two APRs (0.9.12 and 1.2. because they are slotted in Gentoo, meaning they are both installed and matching against virtual packages to satisfy strict dependencies. Sort of having various libstdc++ installed to satisfy old software requirements.

On a closer look, nothing useful depends anymore on apr-0 in my system, and I think I can safely ditch the 0.9.12 version. Eventually, I'll reinstall it. Now I have only apr-1 installed, and make-SL can again safely guess where apr.h is.

The globbing caused a minor inconvenience, due to some fringe case state (two APRs installed). You can safely ignore my issue, it's obviously on user side.

About the missing libs, basically the ENTIRE content of that directory is not copied in the tar.bz2. It's a bunch of archives and shared objects. The viewer complained to no end and refused to start, until I copied them in the dir pointed by ${LD_LIBRARY_PATH} in the startup script. Actually, it's SConstruct's duty to prepare the tar.bz2, so your script isn't "guilty" of this aspect, either.

About audio, your interpretation certainly deserves consideration. Hmmm... Tofu?

Last bit of info: I succesfully managed to compile (and run!) the viewer with gcc 4.1.2. The wiki was rather radical on stating that it wouldn't work. The source has been fixed?

I managed to find what was wrong with sounds in v1.17.1.0 and later... As I suspected, it is a problem in the SConstruct file: when building as OPENSOURCE, the FMOD support is automatically disabled...

I made a new make-SL version available from the wiki ( https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29#Automated_libraries_and_headers_adjustments.2C_compilation_and_packaging ), which fixes this problem, but LL should release a new SConstruct that would allow to build as not OPENSOURCE without requiring the availability of the libkdu sources...

Henri.

I managed to get 1.17.2.0 working natively on x86-64 as well--there were just a couple of casts it complained about. It had been crashing, but I tracked that down to openjpeg -- the 1.2.0 version wasn't working too well for me, so I switched to 1.1.1. I don't think I have sound either, I guess I should try enabling FMOD. Also, some files / libraries I needed weren't packaged by default, but I was able to copy those over from the i686 install I already had, and the libraries I compiled. And I managed to wedge the Boehm garbage collector in there as well, in case of memory leaks.