[sldev] Improving VS2005 builds -- what's needed?

[Dzonatas]

Soft Linden wrote:
> Dzonatas Sol brought up that VS2005 builds are unusuable during
> today's open source office hours.
VS2005 builds of the current source release are not fully usable. Such 
product is not practically usable. It can be used, but that is about it.

You can build from project files posted on jira, but that only builds 
the viewer and not all the libraries. If you mix VS2003 built libraries 
with a VS2005 built viewer, you will find errors.

Try to run 1.18.0.6.OS.3 as found on OSLCC and you will find an error 
with llviewersse2.dll that won't allow SL to start on Vista. In contrary 
to your SLDev wiki:
https://wiki.secondlife.com/wiki/SLDev-Traffic_21#OpenAL_Patch_-_Windows_Testing_Wanted

... the problem is STL and STDC under MSVS, not FMOD or other such. It's 
the freakin' compiler that is the problem.

Microsoft is well aware of the pain they caused:

https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Open_Source_Libraries

The 1.18.0.6.OS.3 *CLEANY* exploits the problem on Vista.  The 
llviersersse2.dll links in in find and starts just fine. The 
optimization code works perfectly. However, as soon as an API call is 
made that uses STL, Microsoft's code says "[Hey... we aren't going to 
let you do this.. click here to end this application]" It isn't even a 
crash with a unknown cause... its a freak'n compliancy check built-in!

> While we're continuing to use VS2003 internally owing to using a
> monolithic solution file that includes old VS2003 library
> dependencies, I we can't commit to having someone building and running
> QA on 2005 yet.
That is exactly why this "unusable" issue has gone ignored.  LL 
employees can not say they completely do not understand this when it is 
plainly obvious that LL employees have said libraries like Havok depend 
on VS2003. That essentially states it is well known the reason why there 
has been no move to VS2005. That essentially further claims that LL 
employee do know that people who attempt to build the viewer with MSVS 
besides VS2003 will have problems that LL claims they won't support 
("due to dependencies").

 >It would be great if updates were as simple as pulling down a 
community-updated VS2005 project file from a pJIRA.


I've already started that here: 
http://oslcc.svn.sourceforge.net/svnroot/oslcc/sandbox/branches/os/trunk

In that repository exists SConstruct and *.sconscript files to build the 
viewer under unix-like and under VS2005.  For VS2005, it builds 
everything... including all the libraries.  If you don't have the 
source, it downloads them.

Best thing about that script, it even exploits how the viewer should not 
link to STDC. One thing to point out, STDC is safer on Linux (with glibc 
and etc), but under Microsoft... it is a nightmare of security 
concerns.  With the study on this, I can tell you that the makers of 
glibc make it so that their libraries are harder to link to out of 
security reasons than because they want to be GPL greedy.

Microsoft has obviously finally realized this and said.. "[OOPS!  Well 
will just do a client-side update and the enforce the legalities of 
linking code with a compliancy check!]"

>  Still, is there anything we can do/include to simplify
> things if there are other manual repair and update steps you're
> taking? 

Lindens rejoiced at dia de la liberacion, but then what has been 
liberated?  The viewer dependency build against the server? Obviously it 
has not been liberated one bit when LL has to ask open source devs (whom 
LL has push on the street or turned down employment) how to liberate 
their code. Think of that business like instead of some tizzy fit and 
see the reality of what I'm saying.

I pointed out a start in the scons above. It is a start. If I attribute 
that idea to anybody... the credit goes to Rob Linden as he is the one 
who subtly encouraged me to create those scons scripts. It freak'n 
wasted a lot of my time to test them, however.  I've fucking saved that 
LL that time. Don't get me any of the crap that it costs LL devs their 
time unless you want to now officially recognize me as an LL software 
developer!

Second... split the server build to VS2003 and exclude the viewer from 
the VS2003 so that it is mandatory to build the viewer under VS2005. 
You'll find a hell hole of security issues as can be found in the 
revision 98 checkin of 
http://oslcc.svn.sourceforge.net/svnroot/oslcc/sandbox/branches/os/trunk

Cheers!

-- 
Power to Change the Void