Visual Studio 2010

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

It seems when Visual Studio 2010 is installed you are greeted with the most unhelpful message by SCons

Code:

scons: Reading SConscript files ...


scons: *** Visual Studio version '10.0' is not supported
File "C:\cafu\SConstruct", line 120, in <module>

However, the fun part is that you get this message, even when Visual Studio 2008 is installed side-by-side (which SCons does support I am lead to believe).

Is there a fix for this? Or better, a way to make it utilize Visual Studio 2010 so that I can uninstall 2008...

CompilerSetup.py has

Code:

defaultCompilerWin32="vc9";

In it of course.

Carsten · **Posted:** 2010-07-04, 15:51

Dear NVX,
welcome to the Cafu forums! :welcome:

Which version of SCons do you use?

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

Hi Carsen,

The version is v2.0.1.beta.20100627.r5064 however I have also tried with v2.0.0.final.0 on another machine with the same issues.

Python version in both instances is 2.6.5 (x64) running on Windows 7 Ultimate x64.

Carsten · **Posted:** 2010-07-05, 13:31

Hi NVX,
thanks for the details!

As a quick fix, please insert

Code:

MSVC_VERSION = '9.0Exp',

after line 112 of file SConstruct, so that the initialization of envCommon looks like this:

Code:

        # Begin with an environment with settings that are common for debug, release and profile builds.
        envCommon=Environment(
            MSVC_VERSION = '9.0Exp',
            CCFLAGS = Split("/nologo /GR /EHsc"),   # CCFLAGS is also taken as the default value for CXXFLAGS.
            CPPDEFINES = ["_CRT_SECURE_NO_DEPRECATE", "_CRT_NONSTDC_NO_DEPRECATE"],
            LINKFLAGS = Split("/nologo /incremental:no"))

If you're using one of the bigger versions of Visual Studio 2008 (i.e. not the Express Edition), then please use '9.0' instead of '9.0Exp'.

I'm also working on adding support for Visual Studio 2010, and a fix for detecting 9.0 vs. 9.0Exp (and analogously for 8.0 and 10.0) automatically.

Please let me know if the above change works. :up:

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

Appears to be building now, although did throw a few warnings about build_dir being deprecated in favour of variant_dir. Will report back if I encounter any other issues.

Thanks

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

Hmm, seems part way through the compile I got the following error

Code:

scons: building associated VariantDir targets: build\win32\vc9\debug build\win32
\vc9\release
cl /Fobuild\win32\vc9\release\Ca3DE\Both\Ca3DEWorld.obj /c Ca3DE\Both\Ca3DEWorld
.cpp /TP /nologo /GR /EHsc /MT /O2 /Ob2 /J /W3 /WX /D_CRT_SECURE_NO_DEPRECATE /D
_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /DSCONS_BUILD_DIR=build/win32/vc9/release /IL
ibs /IExtLibs /Ibuild\win32\vc9\release\ExtLibs\lua\src /IExtLibs\lua\src
Ca3DEWorld.cpp
cl /Fobuild\win32\vc9\release\Ca3DE\Both\EngineEntity.obj /c Ca3DE\Both\EngineEn
tity.cpp /TP /nologo /GR /EHsc /MT /O2 /Ob2 /J /W3 /WX /D_CRT_SECURE_NO_DEPRECAT
E /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /DSCONS_BUILD_DIR=build/win32/vc9/release
 /ILibs /IExtLibs /Ibuild\win32\vc9\release\ExtLibs\lua\src /IExtLibs\lua\src
EngineEntity.cpp
Libs\Network/Network.hpp(345) : error C2220: warning treated as error - no 'obje
ct' file generated
Libs\Network/Network.hpp(345) : warning C4267: 'initializing' : conversion from
'size_t' to 'unsigned long', possible loss of data
scons: *** [build\win32\vc9\release\Ca3DE\Both\EngineEntity.obj] Error 2
scons: building terminated because of errors.

Thoughts? It is VC9 full, not the express version. I have the x64 compile tools installed and am running on windows 7 if that has anything to do with it, could be the x64 build breaking?

Carsten · **Posted:** 2010-07-07, 13:40

NVX wrote:

Appears to be building now, although did throw a few warnings about build_dir being deprecated in favour of variant_dir.

Ah, sorry, I was assuming that you were using svn head, where these warnings are already fixed.

You can just ignore these warnings for now or get the latest source code from the Subversion repository. I'll also upload new archives with the newer code soon.

Carsten · **Posted:** 2010-07-07, 14:03

NVX wrote:

Hmm, seems part way through the compile I got the following error
[...]
Thoughts? It is VC9 full, not the express version. I have the x64 compile tools installed and am running on windows 7 if that has anything to do with it, could be the x64 build breaking?

Yes, the problem is that you're running the first 64-bit Windows build. ;-)

While Cafu compiles and runs perfectly as 64-bit code under Linux, where the LP64 data model is used, the code is not yet ready to cope with the LLP64 data model that is used under 64-bit Windows.

One option is to find the piece of code starting at line 383 and remove the /W3 /WX from the list of flags, so that the result looks like
Code:
elif compiler=="vc9":
envDebug_Cafu .Append(CCFLAGS=Split("/J"));
envRelease_Cafu.Append(CCFLAGS=Split("/J"));
envProfile_Cafu.Append(CCFLAGS=Split("/J"));

and then to ignore any warnings that the compiler might still emit. However, I can neither foresee if it works, nor provide any help if it doesn't - I currently have no 64-bit compiler under Windows (yet), and so I'd not recommend this approach.
Probably the best option is to add another line to the definition of envCommon. Insert
Code:
TARGET_ARCH = 'x86',
after line 112 of file SConstruct, so that the initialization of envCommon now looks like this:
Code:
# Begin with an environment with settings that are common for debug, release and profile builds.
envCommon=Environment(
MSVC_VERSION = '9.0',
TARGET_ARCH = 'x86',
CCFLAGS = Split("/nologo /GR /EHsc"), # CCFLAGS is also taken as the default value for CXXFLAGS.
CPPDEFINES = ["_CRT_SECURE_NO_DEPRECATE", "_CRT_NONSTDC_NO_DEPRECATE"],
LINKFLAGS = Split("/nologo /incremental:no"))

This will build Cafu as 32-bit code.
Important: After you've made the above change, run scons -c in order to remove the previously built 64-bit files, then run scons again normally.
Alternatively, you can also fix all warnings that the original compile comes up with, and submit them as a patch. This would be the ideal solution and I'd be very grateful for your help.

The second options is probably the most straight-forward, please let me know if it works. :up:

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

Just doing some quick testing I discovered the following

Code:

Windows x86
sizeof(void*) == 4
sizeof(size_t) == 4
sizeof(unsigned long) == 4

Windows x64
sizeof(void*) == 8
sizeof(size_t) == 8
sizeof(unsigned long) == 4

Linux x64
sizeof(void*) == 8
sizeof(size_t) == 8
sizeof(unsigned long) == 8

Notice on Linux x64 that sizeof(unsigned long) == sizeof(size_t) == sizeof(void*), and the same on Windows x86, but on Windows x64 unsigned long is still 32bit. As such, the Windows x64 build would probably break a lot of code which assumes that unsigned long == sizeof(void*).

Also, I've noticed some code that assumes an unsigned long is always 32bit (which, would ironically break Linux x64 runtime, but otherwise build fine, if you're very unlucky)

For example in the same Network.hpp file

Code:

    /// Writes one LongWord (32 Bit) into the data buffer.
    /// @param l LongWord to write.
    void WriteLong(unsigned long l)
    {
        Data.PushBackEmpty(4);
        *(unsigned long*)&Data[Data.Size()-4]=htonl(l);
    }

Perhaps some uint32 uint64 etc types are called for to be unambiguous.

If you'd like I can give you access to a Windows x64 Virtual Machine with Visual Studio installed for development purposes (It is unfortunately on a crappy 1.5Mbit / 256k ADSL line though, but the box is a nice i7, so should have plenty of CPU and RAM available for compilation), I'm guessing that a lot of code would need to be touched in order to fix x64 properly and I'm still only just getting a feel for the Cafu code base, go figure.

Carsten · **Posted:** 2010-07-09, 18:53

Hi NVX,

NVX wrote:

Notice on Linux x64 that sizeof(unsigned long) == sizeof(size_t) == sizeof(void*), and the same on Windows x86, but on Windows x64 unsigned long is still 32bit.

Yes, these are the ILP32, LLP64 and LP64 data models, respectively. See e.g.

for additional information.

Quote:

As such, the Windows x64 build would probably break a lot of code which assumes that unsigned long == sizeof(void*).

Yes, indeed. However while I'm in hindsight somewhat unhappy about the rather extensive use of unsigned longs in the Cafu code (big parts of which were written before 64-bit systems became a conscious factor), I don't think that that now is a big problem:

Assumptions like sizeof(unsigned long) == sizeof(void*) should be very rare in all Cafu code, and
the Linux LP64 code already compiles and works very reliably (which of course doesn't mean that no more bugs are in it).

In summary I'm quite confident that the port to LLP64 is feasible with reasonable or even little effort.

Quote:

Also, I've noticed some code that assumes an unsigned long is always 32bit (which, would ironically break Linux x64 runtime, but otherwise build fine, if you're very unlucky)

For example in the same Network.hpp file

Code:

    /// Writes one LongWord (32 Bit) into the data buffer.
    /// @param l LongWord to write.
    void WriteLong(unsigned long l)
    {
        Data.PushBackEmpty(4);
        *(unsigned long*)&Data[Data.Size()-4]=htonl(l);
    }

Perhaps some uint32 uint64 etc types are called for to be unambiguous.

Ahhh, you've identified one of the few (at least according to my still unverified claim...) spots that are problematic. You're right regarding the solution as well: uint32 and similar types should rather be used here.

Quote:

If you'd like I can give you access to a Windows x64 Virtual Machine with Visual Studio installed for development purposes

Wow, that would be very kind of you :wohow:

- how exactly would I be able to access that VM?

Quote:

I'm guessing that a lot of code would need to be touched in order to fix x64 properly

Yes, ripple effects from changing to types like uint32 can indeed imply plenty of edits...

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

Ugh, so there's an actual name for it other than Microsoft being difficult. Nice links, thanks for that.

I suspect the WriteLong function functions as expected because data is written forwards, and a count is used by the looks of it, so if you have an empty buffer, and call WriteLong(1) the buffer ends up having 4 bytes written to it physically, but the counter only is incremented by 4, so it ends up munging the extra bytes next write, or when the packet is sent off to the network (although come to think of it, it uses big-endian - hence the htonl - so if you wrote 1, youd think it'd end up being 0 that -actually- gets written in the first 4 bytes, if it was little endian it'd work bug free... rather odd it hasn't broken now that I think of it... or mabe it's just not been noticed)

VM Access - your choice, Remote Desktop is probably easiest being windows and all, although I can install VNC/etc if you'd like. Do you use any form of Instant Messaging, or IRC? Probably easier to discuss via there.

Carsten · **Posted:** 2010-07-12, 16:32

Hi,

NVX wrote:

... rather odd it hasn't broken now that I think of it... or mabe it's just not been noticed)

Yes... even though the signature of htonl() on my Ubuntu 10.04 system is

Code:

extern uint32_t htonl (uint32_t __hostlong)

your arguments are still to the point and this really should be fixed.

Quote:

VM Access - your choice, Remote Desktop is probably easiest being windows

Ok, sounds great! I've replied to your recent PM for the details. :up:

NVX · **Joined:** 2010-07-04, 07:30 **Posts:** 10

Carsten wrote:

NVX wrote:

... rather odd it hasn't broken now that I think of it... or mabe it's just not been noticed)

Yes... even though the signature of htonl() on my Ubuntu 10.04 system is

Code:

extern uint32_t htonl (uint32_t __hostlong)

your arguments are still to the point and this really should be fixed.

ah-ha! That's exactly why it hasn't broke, the htonl() is equivalent of casting it to a 32bit int, thus ignoring the lower half, and returning only 4 bytes, which is why it works. Was so confused before why it hadn't broken, but htonl() explains it, saved by network byte order

The open-source game engine and graphics engine for multiplayer, cross-platform, real-time 3D action

Visual Studio 2010

Who is online