Difference between revisions of "Talk:Compiling the viewer (MSVS2005)"

From Second Life Wiki
Jump to navigation Jump to search
(New section: STL compliant?)
 
(12 intermediate revisions by 8 users not shown)
Line 1: Line 1:
== Crashes on edit ==
I can compile the source for 1.17.1.0 to 1.17.3.0 using VS 2005, but when I do (regardless of if its for ReleaseForDownload or ReleaseNoOpt) I get a buggy executable.  What I mean is that, when using the compiled version, right-clicking and hitting "Edit" on objects I don't own causes a crash.  I know there was an edit bug in 1.17.1.0, but that was fixed in 1.17.2.0 and 1.17.3.0 and I compiled each version in it's own folder independent of the rest.
When I just download and install the normal binary from Second Life, it does not crash when I edit an object I don't own.
Editing objects I own works fine.  Has anybody else experienced something like this?  What could I be compiling wrong?
-- [[User:Squash Otoro|Squash Otoro]] 17:33, 07 July 2007 (PST)
== Work Around for the preprocessor stuff ==
I worked around the work around. I hated how time consuming it was to alter it one by one. This reduces the time required to set up your environment considerably.
--[[User:Blakar Ogre|Blakar Ogre]] 02:01, 9 June 2007 (PDT)
Wow, good job, Blakar!  That particular preprocessor macro part was long a headache for me.  Thank you very much  for sharing the neat trick!
--[[User:Alissa Sabre|Alissa Sabre]] 05:18, 9 June 2007 (PDT)
I think it should be possible to handle the Wchar_t type the same way.  At least that seems to promote the "no" into all configurations as well.  Does not seem to work for WarnAsError as the Lindens seem to have chosen a non-default parameter here
    <Tool
        Name="VCCLCompilerTool"
        PreprocessorDefinitions="_VC80_UPGRADE=0x0710;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_USE_32BIT_TIME_T"
        TreatWChar_tAsBuiltInType="false"
    />
    <Tool
        Name="VCResourceCompilerTool"
        PreprocessorDefinitions="_VC80_UPGRADE=0x0710;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_USE_32BIT_TIME_T"
    />
-- [[User:Nicholaz Beresford|Nicholaz]] 06:20, 9 June 2007 (PDT)
== Clean up ==
Work arounds clean up:<br>
- unistd.h: not (no longer?) applicable. Was not necessary while using Express for 1.16.0.5 nor for 1.17.0.9.<br>
- llwindowwin32.cpp: It's fixed so no point in keeping it there<br>
- Missing resources: Corrected the fix, artwork downloads are available.<br>
- 1.15.0.2: not applicable to current versions<br>
Problems running clean up:<br>
If everybody correctly downloads the artwork package we no longer need to mention fixes here for missing files that are part of the artwork package.
--[[User:Blakar Ogre|Blakar Ogre]] 02:01, 9 June 2007 (PDT)
== Code Edits ==
== Code Edits ==
I'm not sure casting all the time() calls should be done. It's more code edits, and time_t is still a 64bit typedef, which could cause issues besides just compiling that may be hard to find. I would suggest taking out all those code edits and putting _USE_32BIT_TIME_T preprocessor definition in the needed projects. --[[User:Bane Darrow|Bane Darrow]] 17:02, 9 January 2007 (PST)
I'm not sure casting all the time() calls should be done. It's more code edits, and time_t is still a 64bit typedef, which could cause issues besides just compiling that may be hard to find. I would suggest taking out all those code edits and putting _USE_32BIT_TIME_T preprocessor definition in the needed projects. --[[User:Bane Darrow|Bane Darrow]] 17:02, 9 January 2007 (PST)
Line 72: Line 117:


--[[User:Maximilan DeSantis|Maximilan DeSantis]] 12:25, 10 February 2007 (PST)
--[[User:Maximilan DeSantis|Maximilan DeSantis]] 12:25, 10 February 2007 (PST)
== How to build mozilla under VC8 ==
Found this link, and it may help: http://developer.mozilla.org/en/docs/VC8_Build_Instructions 00:48, 12 March 2007 (PDT)
Mozilla debug lib doesn't seem to have been compiled for debug in 16.1.5 . This is a show stopper in linking until I can find a hack or compile it myself. [[User:Singular Seoul|Singular Seoul]] 2007-05-28 17:42 (EET+1)
== FMOD Libraries ==
In the FMOD section, it says to rename the libraries if they have an "ex" in them. I downloaded FMOD Ex 4.06 version instead of 3.75 (which it does say you need) and when I renamed the FMOD Ex libs (like it says you can do), I got lots of errors. I have removed the renaming part of that section and emphasized that you need 3.75.
I couldn't find 3.75 here http://www.fmod.org/index.php/download/find. I'm googling for a source. --[[User:Radslns Hutchence|Radslns Hutchence]] 09:34, 19 January 2008 (PST)
== STL compliant? ==
What the heck is STL compliance? I cannot find anything on Google explaining this, and Wikipedia has nothing. [[User:Scalar Tardis|Scalar Tardis]] 20:26, 20 June 2008 (PDT)

Latest revision as of 20:26, 20 June 2008

Crashes on edit

I can compile the source for 1.17.1.0 to 1.17.3.0 using VS 2005, but when I do (regardless of if its for ReleaseForDownload or ReleaseNoOpt) I get a buggy executable. What I mean is that, when using the compiled version, right-clicking and hitting "Edit" on objects I don't own causes a crash. I know there was an edit bug in 1.17.1.0, but that was fixed in 1.17.2.0 and 1.17.3.0 and I compiled each version in it's own folder independent of the rest.

When I just download and install the normal binary from Second Life, it does not crash when I edit an object I don't own.

Editing objects I own works fine. Has anybody else experienced something like this? What could I be compiling wrong?

-- Squash Otoro 17:33, 07 July 2007 (PST)

Work Around for the preprocessor stuff

I worked around the work around. I hated how time consuming it was to alter it one by one. This reduces the time required to set up your environment considerably.

--Blakar Ogre 02:01, 9 June 2007 (PDT)

Wow, good job, Blakar! That particular preprocessor macro part was long a headache for me. Thank you very much for sharing the neat trick!

--Alissa Sabre 05:18, 9 June 2007 (PDT)

I think it should be possible to handle the Wchar_t type the same way. At least that seems to promote the "no" into all configurations as well. Does not seem to work for WarnAsError as the Lindens seem to have chosen a non-default parameter here

   <Tool
       Name="VCCLCompilerTool"
       PreprocessorDefinitions="_VC80_UPGRADE=0x0710;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_USE_32BIT_TIME_T"
       TreatWChar_tAsBuiltInType="false"
   />
   <Tool
       Name="VCResourceCompilerTool"
       PreprocessorDefinitions="_VC80_UPGRADE=0x0710;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_USE_32BIT_TIME_T"
   />

-- Nicholaz 06:20, 9 June 2007 (PDT)

Clean up

Work arounds clean up:
- unistd.h: not (no longer?) applicable. Was not necessary while using Express for 1.16.0.5 nor for 1.17.0.9.
- llwindowwin32.cpp: It's fixed so no point in keeping it there
- Missing resources: Corrected the fix, artwork downloads are available.
- 1.15.0.2: not applicable to current versions

Problems running clean up:
If everybody correctly downloads the artwork package we no longer need to mention fixes here for missing files that are part of the artwork package.

--Blakar Ogre 02:01, 9 June 2007 (PDT)

Code Edits

I'm not sure casting all the time() calls should be done. It's more code edits, and time_t is still a 64bit typedef, which could cause issues besides just compiling that may be hard to find. I would suggest taking out all those code edits and putting _USE_32BIT_TIME_T preprocessor definition in the needed projects. --Bane Darrow 17:02, 9 January 2007 (PST)


I think ultimately things will migrate to 64bit. I had just built boost when I noticed the 2005 Express was up. And may as well delete the page I was maintaining through a link on the Common_compilation_problems section, since it is much the same, and I hadn't resolved the linker errors of boost & mozilla. Also, with the #pragma warning(disable : 4996) lines, ";_CRT_SECURE_NO_DEPRECATE" is not needed. And perhaps the std::hash_multimap to stdext::hash_multimap namespace change should be managed by a #if (_MSC_VER >= 1400) too. -- Paula Innis 19:11, 9 January 2007 (PST)

Boost

I don't think it's necessary to compile Boost and Boost-Regex yourself, you can download everything you need with a nice installer available here: http://www.boost-consulting.com/download.html and just drop the regex library in the appropriate directory. --Eddy Stryker 00:55, 10 January 2007 (PST)

lscript_compile_fb

bison insists on outputting a .hpp file rather than a .h file, I added the following line at the end of the custom build command for indra.y

"@IF EXIST ytab.hpp copy ytab.hpp ytab.h /Y >NUL"


The custom build step uses "C:\cygwin\..." explicitly, which could cause it to fail if it is located elsewhere. If you have cygwin in your PATH, you can erase "C:\cygwin\bin\" portion of each command. Dzonatas Sol 15:03, 11 January 2007 (PST)


Can someone please point us to where we can find the "custom build command" that needs to be edited? Synthalor Mandelbrot 12:36, 19 January 2007 (PST)


O, silly me! Right click on indra.y and click on "Properties." The Command Line field needs to be changed in "General" under "Custom Build" on the indra.y Property Page that will come up. Synthalor Mandelbrot 11:24, 3 February 2007 (PST)


I got mine to work by having bison.exe along my path and removing the prefix portion, as Dzonatas Sol described.

BUT! If you have further errors, go to a Command Prompt and type in 'bison --help'." You may get an error, as I did, that bison couldn't find one of its dependencies, cygintl-3.dll (that's a lowercase 'L', not a '1'. This is because of a nasty bug in some recent Cygwin installers.

Go get the newest Cygwin setup.exe. Click through the usual updating routine, select the "Full" view, and go find "libintl3." Mark it to be installed or reinstalled.

You might as well also mark "libintl2," because you are going to need it when you go through this same drill to get indra.l functioning. Flex will need libintl2 and it probably won't be there for you either. You can check this by typing "flex --help" from the Command Prompt. If it fails, you need libintl2.

I marked both bison and flex for reinstall, also, just for good luck!

After the Cygwin setup completes, try typing "bison --help" from the Command Prompt again. It should succeed. If so, you should be ready for indra.y. Also, try typing "flex --help" from the Command Prompt to see if you're ready for indra.l.

Now, you probably also need to edit the custom build step for indra.l. Either clear the cruft from in front of 'flex', or make sure it matches your machine's path to the Cygwin 'bin' directory.

In theory, you are now ready to recompile and those particular nastinesses should go away and let you get on with your next group of errors!

Enjoy!

Synthalor Mandelbrot 12:42, 3 February 2007 (PST)

unistd.h

Need a place to find a compatible unistd.h and such headers if one doesn't already have them. (non-gcc specific) The Express version doesn't include these. Dzonatas Sol 15:36, 11 January 2007 (PST)

Looks like an empty libraries/include/unistd.h will work fine to get around this. Dzonatas Sol 19:30, 11 January 2007 (PST)

Compile error on APR headers

For some reason it compiled everything except files that used llapr.h because it said it couldn't find some apr-1 header files. I did a quick hack and copied the apr-1 headers from libraries/i686-win32/include/apr-1 to libraries/include/apr-1 and it compiled fine. The only thing I have noticed different so far is an extra backslash at the end of the Additional Includes under project properties. Dzonatas Sol 13:55, 11 January 2007 (PST)

Disable llMozLib for Windows?

Where are the instructions for adding in llMozLib for windows? Does anyone know how to add this feature in?

Code Editing

Sections for Code Editing is now cluttering. (See contents for the current structure.)

Is the Misc. Code Editing part of slviewer-src-20070112a or independent from any specific versions?

How about Disable llMozLib that appear twice?

I'd like to break the Code Editing into two parts: version specific changes and version independent ones, but I'm not sure where the above two items belong...

--Alissa Sabre 06:37, 6 February 2007 (PST)

Disable llMozLib is version independent, as long as someone doesn't find a way to build it. The Misc. Editing belongs to a specific version, I think.

--Maximilan DeSantis 12:25, 10 February 2007 (PST)

How to build mozilla under VC8

Found this link, and it may help: http://developer.mozilla.org/en/docs/VC8_Build_Instructions 00:48, 12 March 2007 (PDT)


Mozilla debug lib doesn't seem to have been compiled for debug in 16.1.5 . This is a show stopper in linking until I can find a hack or compile it myself. Singular Seoul 2007-05-28 17:42 (EET+1)

FMOD Libraries

In the FMOD section, it says to rename the libraries if they have an "ex" in them. I downloaded FMOD Ex 4.06 version instead of 3.75 (which it does say you need) and when I renamed the FMOD Ex libs (like it says you can do), I got lots of errors. I have removed the renaming part of that section and emphasized that you need 3.75.

I couldn't find 3.75 here http://www.fmod.org/index.php/download/find. I'm googling for a source. --Radslns Hutchence 09:34, 19 January 2008 (PST)

STL compliant?

What the heck is STL compliance? I cannot find anything on Google explaining this, and Wikipedia has nothing. Scalar Tardis 20:26, 20 June 2008 (PDT)