[sldev] 1.20.12 build problem on Windows regarding STL compatibility issue

[Alissa Sabre]

Thank you, Chalice and Soft, for comments.

> Yes, 1.20 is still VS2003-based.
> From 1.21 going forward, VS2005 will be the standard.

Yes, I know it.

What I don't know is how those Linden devs working on 1.21 with
VS2005 internally overcame the Microsoft STL compatibility issue.

> I know others have gotten
> VS2005 to work with the 1.20 drop, so don't be dissuaded

It's a good news.

> I had that issue described below when compiling 1.20 RC12 with VS2008 Express.

> Try compiling again with the ReleaseForDownload setup in your
> VS2005...I'd be interested
> to hear if you still get this issue.

Well, I have already tried both builds, and there are no differences.

More precisely,

* A ReleaseNoOpt build run under debugger ... access violation,
* A ReleaseForDownload build run under debugger ... access violation,
* A ReleaseNoOpt build run without debugger ... 100% CPU before opening window, and
* A ReleaseForDownload build run without debugger ... 100% CPU before opening window.

When removed _SECURE_SCL=0, executables both from ReleaseNoOpt build
and from ReleaseForDownload build run fine.

I'm almost sure _SECURE_SCL=0 is causing problem in 1.20.12.  What I'm
not sure is whether the _problem_ that were observed before June 2007
and _solved_ by adding _SECURE_SCL=0 is still there.  If it is, simply
removing _SECURE_SCL=0 is not a real solution.  I guess I can avoid
both issues by rebuilding boost *.lib with _SECURE_SCL=0, but I'm too
lazy to even think of doing it by myself.  (boost has its own custom
build system, BoostJam, that seems unordinary enough to make me off
from it.)

    Alissa Sabre
--------------------------------------
Stop! Global Warming ~ Yahoo! JAPAN Earth Project
http://pr.mail.yahoo.co.jp/earthproject/