[sldev] 1.20.12 build problem on Windows regarding STL
compatibility issue
Ambrosia
chaosstar at gmail.com
Wed Jul 9 09:30:38 PDT 2008
I had that issue described below when compiling 1.20 RC12 with VS2008 Express.
What surprises me here is that you are having the same issue with
VS2005..it compiled (well, ran)
fine for me there. Tho I must note, I did compile ReleaseForDownload,
in both cases.
Try compiling again with the ReleaseForDownload setup in your
VS2005...I'd be interested
to hear if you still get this issue.
Also, LL use VS2003 .net for the compilation of the official viewer,
to my knowledge.
--Chalice Yao
On Wed, Jul 9, 2008 at 16:29, Alissa Sabre <alissa_sabre at yahoo.co.jp> wrote:
> Developers,
>
> I'm having a trouble building/running recent 1.20 series of SL viewer
> on Windows using VS2005. I believe it is related to the compatibility
> issues on Microsoft implementation of STL, in particular, that related
> to "safe iterator", although I'm not exactly sure...
>
> I put two essential questions on the bottom of this mail. Any
> comments are appreciated.
>
> ---
>
> I downloaded and built SL viewer 1.20.12 on my Windows using Visual
> C++ Express 2005. I converted solution/project files by myself
> following the instructions on:
>
> http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005
>
> The compile seemed successful. However, When executed alone, it does
> not show any window, consuming 100% CPU until I terminate the process.
> When executed under debugger, it stopped before showing any window
> with the following message:
>
> Unhandled exception at 0xXXXXXXXX in newview_noopt.exe: 0xC0000005:
> Access violation reading location 0xXXXXXXXX.
>
> and the top entries of the stack trace shows something like:
>
> std::list<XXX>::begin()
> boost::signals::detail::named_slot_map_iterator::init_next_group()
> boost::signals::detail::named_slot_map::end()
>
> and I found the code for boost::signals::detail::named_slot_map::end()
> is taken from the boost library file
> libboost_signals-vc80-mt-s-1_34_1.lib contained in the SL library
> bundle.
>
> After examined the issue with debugger, I had a feeling that the size
> (as in sizeof()) of some variable is understood incorrectly. And I
> remembered the _SECURE_SCL=0 issue regarding Microsoft VS2005 STL's
> iterator issues:
>
> https://lists.secondlife.com/pipermail/sldev/2007-June/002791.html
>
> My compiler options included the define for _SECURE_SCL=0 because the
> wiki page says so... I removed the define for _SECURE_SCL=0 from the
> compiler options, and buildt again.
>
> The resulting executable worked fine.
>
> The mail by Matt Kimmel says, however, this _SECURE_SCL=0 define is
> essential for VS2005 build, and the viewer frequently crashes without
> it. (Although I have not experienced any crash of my own build of
> 1.20.12 viewer without _SECURE_SCL=1 for about three or four hours.)
>
> On the other hand, it is apparent that the *.lib files of pre-compiled
> boost package is build without _SECURE_SCL=0 settings, so the
> application that use boost library needs to use the same settings.
> That's what I believe caused my initial problem.
>
> I'm not sure what I should do. In particular, I want to know answers
> to the following two questions:
>
> (1) I believe Lindens are using VS2005 for their own viewer
> development. What settings are you using when compiling the
> viewer, regarding _SECURE_SCL?
>
> (2) Matt Kimmel's mail above says the (viewer side) problem is in
> LLSD::impl class, although he is not specific enough... Is the
> problem in LLSD::impl corrected after June 2007?
>
> # I'm not sure why this issue is not discussed on JIRA or SLDev... I
> was off from SL development for a while. Nobody is working on
> Windows anymore?
>
> Thanks in advance,
>
> Alissa Sabre
> --------------------------------------
> Stop! Global Warming ~ Yahoo! JAPAN Earth Project
> http://pr.mail.yahoo.co.jp/earthproject/
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
More information about the SLDev
mailing list