Difference between revisions of "Talk:Build the Viewer on Linux"

From Second Life Wiki
Jump to navigation Jump to search
m (typo)
(Required Headers)
Line 41: Line 41:


* linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h
* 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.
Autoconf is a wonderful tool. :P

Revision as of 03:08, 12 April 2007

You need yacc too --Eddy Stryker

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


Isn't it nescessary to use scons with the option OPENSOURCE=no since the source tarball of 2007-01-12, if you wanna use the fast KDU image decoding libraries? I haven't tried thus I am not sure and didn't add it, but the following code block taken from the SConstruct file seems to indicate it:

	if opensource == 'yes':
		flags += '-DLL_USE_KDU=0 '
	else:
		flags += '-DLL_USE_KDU=1 '

--Sharven Raabe 03:47, 14 January 2007 (PST)

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)

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)

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.

Autoconf is a wonderful tool. :P