Talk:Build the Viewer on Linux

From Second Life Wiki
Jump to navigation Jump to search

I had to add "class LLUICtrlFactory;" to llui/lluictrl.h and llui/llviewborder.h to avoid a bunch of problems about that class missing --Eddy Stryker

llmozlib

As Tofu wrote (Feb 23 2007), "you shouldn't generally need to download and build LLMozLib for a SL viewer build unless you're hacking on LLMozLib itself or porting SL to a platform which we don't supply pre-built libraries for".

Nonetheless, there's a need of instructions on

and/or

--Boroondas Gupte 06:10, 26 February 2007 (PST)

I edited it so it's complete if you want llMozLib off, getting llMozlib compiled and working with the viewer is actually nontrivial, compiling llMozLib is just about as hard as compiling the viewer itself! Gigs Taggart 08:06, 27 February 2007 (PST)
What functionality is lost if you do not use llmozlib? Meyaden Beck 20:11, 12 April 2007 (PDT)
You won't have any in-viewer browser windows (e.g. F1-Help) as well as no HTML login screen (you'll get the old login screen with the static picture instead). Opening pages in an external browser from within SL (e.g. links in chat/IM) won't be affected, nor will be inworld actions triggered by your external browser (e.g. SLUrl). --Boroondas Gupte 06:57, 7 May 2007 (PDT)

mozjs

A similar problem seems to be present with beta-1.13.4.3, only that it's -lmozjs not -lllmozlib that's failing at linktime. I can't even seem to locate the corresponding header file (expected filename 'mozjs.h') so it might well be that the problem only looks similar to the llmozlib one, but actually isn't. I'll post to the [sldev] list as soon as I have investigated this further. --Boroondas Gupte 11:22, 1 March 2007 (PST)

FMOD

This non-open-source audio library is a continuous source of irritation to open-source devotees and 64-bit devotees alike (it only comes in 32-bit), so it needs early replacement. But not replacement by another full-function audio subsystem. A much better approach is available.

Every platform has audio players available, or 20 of them, so why reinvent the wheel and bloat the client unnecessarily? Write only a software mixer to combine the various audio sources together, and present the output at an Icecast-type stream listener interface on a local socket. Then the local player of choice can connect to it just like to any Internet radio, and you're done. You can even launch the player to make it seamless.

I bet that this would make the client shrink enormously too! And the icing on the cake is that the separate player will naturally run on another core on modern multicore machines. --Morgaine Dinova 18:03, 12 October 2007 (PDT)

FMOD instructions

Section "Recommended libraries and headers" of this page DON'T contain any information about libfmod dependency and needed version of libfmod. Current sources (http://hg.secondlife.com/viewer-development, http://hg.secondlife.com/viewer-release) refers to libfmod-3.75. But this version is very old, and official fmod site don't contains any links to this version. Tikhon Golitzen 20:05, 2 January 2011 (UTC)

As already noted in a jira comment, the FMOD specific steps have been removed from the Linux build instructions on the wiki this summer, some time after openAL had become SL's default sound system on Linux.
The page's revision as of 01:36, 7 July 2010 is the last to still include these steps, but is probably quite outdated now. And due to Merov's changes (STORM-137), the paths where the binaries would have to be placed changed anyway (or is that only for Windows?). These changes also made FMOD default to ON, so I've included instructions on the main page for disabling fmod, to continue using openAL instead.
SL can't use newer fmod versions. Download links to the old, compatible versions can be found at the fmod forum.
--Boroondas Gupte 12:31, 3 January 2011 (UTC)
Thanks! Tikhon Golitzen 20:52, 3 January 2011 (UTC)

Help?

Would it be useful to add a blurb on where people can get help compiling, specifically in Linux. Or at least an internal link to another wiki page that has a list of places to get help in each version, MAC/WIN/LIN/BSD/(however far people want to break it down, etc.).

little helper script

For those of you who don't want to copy-paste from this article for every build they compile, I put a little bash script I'd liked to share in my user space: User:Boroondas_Gupte/unpack.sh. It just does a part of what's explained in this article. --Boroondas Gupte 09:59, 6 March 2007 (PST)

Error?

Under the heading "fix shell scripts" there is a header file listed. can someone else confirm this should not be in that list, and if it should, why does it not have a #!/bin/sh at the top of it?

  • linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h

Required Headers

Is there a reason that the instructions include copying header files to the source tree?

I have not attempted the install yet, that will probably be in a few days for me. However, most packages don't require the copying of header files from any standard lib into their own source directories. I am not sure if this practice is really a good one.

Will the package not compile if the headers are simply in their proper locations? If so, this is something that the developers may want to consider fixing. I would personally consider that a bug.

Normal procedure with most apps is to have the librarries propperly installed, and have the code or makefile written so that it looks in the right place. Meyaden Beck 19:41, 12 April 2007 (PDT) (I forgot to sign before I think)

Autoconf is a wonderful tool. :P

This setup is so that a fixed build of included libraries are setup for each branch and platform. The host platform can change independently of the SL build. Also, isolation of these libraries greatly reduce debug issues. There are a few patches to use the host platform's installed libraries instead. However, a few changes still need to be made for consistency. Dzonatas Sol 11:58, 12 April 2007 (PDT)
Hmmm... I see, I think. My next question (and if I get the time I may fix this one myself), why the choice to pretty much ignore compilation of llMozlib? Stating that "Compiling it is a pain, and this is how you disable it", doesn't look good. I haven't gotten that far in my current Linux install yet. I just finished installing XFce4, but as soon as I get OpenOffice.org and Blender installed, I will likely move on to Second Life. When I do, I will go through the steps of compiling llMozlib and take notes on what I did to make it work. :-) I should probablly also make sure to include a warning that I am using an LFS build. However, the instructions the LFS site uses to build most packages should theoretically work for just about any system. ^_^Meyaden Beck 19:41, 12 April 2007 (PDT)

Hmm. I believe older versions of this page clearly showed instractions for those who just want to compile viewer only and for those who want to build everything. I believe the older style is better.

Are there anyone who objects to such reorganization?

--Alissa Sabre 22:51, 8 June 2007 (PDT)

I agree to every kind of reorganization, since this page is a bit messy. We should provide a simplified version of it, at least. I think it's a bit scary for newbies. So today I moved the 'Packaging errors' section to Common compilation problems page (we may want to give more visibility to that link); I removed the 'Fix Shell Scripts' because I think it has been fixed; I added some questions where I think we need to being more informative; It looks like you only need to add FMOD=no to the scons command, and I think we should give this information only - i'm not sure about this, so in the meantime I just made some changes to both 'Prerequisites' and 'Copy headers and libraries into the source tree' sections.

Please reverse my changes if not appropriate! I'm OK with a reorganization of this page. Pleae do a new page version for every edit, using proper comments, so revert is easier. --Signore Iredell 06:42, 9 June 2007 (PDT)

Note that gcc-3.4 is NOT required, patches to fix compiling on gcc 4.x were among the first to be merged after the source release. I've been compiling with gcc 4.x from the beginning and it works fine. I'm not sure how to rework the article though, SConstruct is hardwired to call g++-3.4 which won't even work with Fedora's compat compiler (which is named g++34), which does not seem to be mentioned in the article either. Please merge VWR-218 ;P Seg Baphomet 12:39, 13 June 2007 (PDT)

Gentoo 64bits?

Hello,

Did anyone get it compile on Gentoo 64bits? Iann Alderson 04:19, 7 October 2007 (PDT)

  • Needed packages:
    • dev-libs/boost
    • dev-util/scons
    • media-libs/gstreamer

Ok, it compiles alright for well over an hour, which is better than I expected. ;o)

But the, I get 

cc1plus: warnings being treated as errors
/tmp/yann/usr/local/src/linden/indra/i686-linux-client-release/newview/viewer.cpp: In function 'BOOL do_elfio_glibc_backtrace()':
/tmp/yann/usr/local/src/linden/indra/i686-linux-client-release/newview/viewer.cpp:2423: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
scons: *** [/tmp/yann/usr/local/src/linden/indra/i686-linux-client-release/newview/viewer.o] Error 1
scons: building terminated because of errors.

Does anyone know what that means? Thanks, Iann Alderson 11:24, 7 October 2007 (PDT)

It's been a while, but for completeness's sake: gcc lets one make the compiler very finicky, so that things that are normally just warnings are considered errors that will make the compile fail--that way you can fix more stuff at compile time, rather than leaving possible errors to barf at runtime. In this particular case, someone has a *printf() call that has a constant format string, so that the compiler can type check the corresponding arguments, and there's a %d (which is used to print int values) corresponding to a value of type size_t, which is typically unsigned, and for a 64-bit system may well be larger than int, which is likely to make printf fail to properly access any following values to be printed. --Melissa Yeuxdoux 01:33, 31 December 2008 (UTC)

http://pastebin.ca/729141

OpenAL

OpenAL should be listed under the "Installing the required libraries" section, right? libopenal-dev and libalut-dev -- Everclear Quandry 02:58, 15 March 2009 (UTC)

gnu/stubs-32.h : No such file or directory

It seemed that on Ubuntu (at least) installing the package libstdc++6 add the library libstdc++.so.6.

SL build requires a link libstdc++.so

Typing this command fix the issue: 

sudo ln -s /usr/lib32/libstdc++.so.6 /usr/lib32/libstdc++.so

Compiling on Ubuntu 10.10+

Is there any guide for compiling the viewer under the newer versions of Ubuntu? I decided to try first under 10.10 (maverick), then right now under 11.04 (natty) but when I got to the point of setting the standalone libraries up, I found that the OMVViewer repository holding some of them only has packages for up to 10.04 (lucid), and the sources to them are nowhere to be found. Nedrae Messmer 00:17, 19 June 2011 (PDT)

Have you tried a default (i.e. non-standalone) build? In non-standalone build mode, many dependencies are downloaded automatically to the build dir, so you don't have to install them to your system. This instruction page is probably not fully up-to-date for autobuild, yet (our new meta-buildsystem), so you might have to ask on IRC.
--Boroondas Gupte 13:23, 19 June 2011 (PDT)
I haven't tried non-standalone, since I'm on 64-bit (should've mentioned that from the start) and this bit states that for native 64-bit (to use the gstreamer libraries mainly) I must do standalone. Or have things changed since then? Nedrae Messmer 17:12, 19 June 2011 (PDT)
Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:Build_the_Viewer_on_Linux&oldid=1147060"