Response at bottom. (Well, except for this line.)

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Friday, June 26, 2009 4:30 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compile errors inside boost::asio code I can't affect.

AMDG

Michael.Broida@thomsonreuters.com wrote:

...

We've been using Boost 1.38.0: WinXP SP3 on 32-bit box VisualStudio 2005, MSVC++ 8.0, 32-bit builds.

I've just rebuilt Boost 1.38.0 on another system for 64-bit builds: Windows Server 2008 Enterprise SP1 VisualStudio 2008, MSVC++ 9.0, 64-bit builds.

Found no visible build errors during the Boost build.

Since Asio doesn't have a compiled library, it's not very important whether you can build the libraries or not (except for Boost.System on which Asio depends).

...

Yet when I build our own code on the 64-bit system, I get these three compile errors deep inside boost::asio code that I have no control over:

error C2664: 'QueueUserAPC' : cannot convert parameter 1 from 'void (__cdecl *)(ULONG)' to 'PAPCFUNC'

D:\dev\3rdParty_x64\include\boost\asio\detail\win_thread.hpp 151

...

<snip>

Party_x64\include\boost\asio\detail\win_iocp_io_service.hpp 430

The "D:\dev\3rdParty_x64" is where I've installed the

includes & libs

...

for Boost and other components.

As you can see, those errors are not in our code; they're deep in the ASIO code itself, and I don't see how we could be causing them. I didn't write our code that uses ASIO, so I don't know anything about what ASIO is trying to do there. :(

Since I couldn't find any other complaints online about this, I'm flailing around for support.

Any pointers would be appreciated.

Pertinent data: 64-bit WindowsServer2008 SP1 on Intel 64-bit box VisualStudio2008 SP1 (SP2 is still RC, I think, so we can't use it.) Our projects using "x64" configuration, so uses x64 compiler. Boost built with x64 compiler via: toolset=msvc-9.0 address-model=64

Can you run Asio's tests? The command is bjam <options> libs/asio/test

Done. I'm not sure what to look for in the test output. Is there a good string indicating "failed" that I can search for? ("fail" doesn't appear anywhere.) I ran that with the same options I used to build Boost. I specify build-dir, stagedir, libdir, includedir, but most may be unnecessary for this test. Then I use: --layout=versioned (hmm, is that supposed to start "--"?) toolset=msvc-9.0 address-model=64 link=static threading=multi runtime-link=static define=_SCL_SECURE_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_CRT_NONSTDC_NO_DEPRECATE I don't -see- any failures or errors. There are some warnings, though: a) "decorated name length exceeded" (OK, I think) b) "conversion from 'size_t' to 'DWORD'" (didn't expect those) c) "calling _set_se_translator() requires /EHa (how to specify /EHa to bjam??) d) "conversion from 'SOCKET' to 'int' (goes away in re-run below!!) e) "'boost::asio::basic_socket::cancel': By default, this function always fails with operation_not_supported when used on Windows XP, Windows Server 2003, or earlier." (I think that may indicate _WIN32_WINNT is -not- being set correctly by the compiler, as another person suggested.) Then I re-ran it with the above options + some options used when we build our own projects: define=WIN32 (some "old" code wants that instead of _WIN32) define=WIN32_LEAN_AND_MEAN (avoids some system stuff we don't need?) define=_WIN32_WINNT=0x0600 define=BOOST_THREAD_USE_LIB (we don't use Boost threads, but future: don't want dlls) I have been letting the compiler define _WIN64 and _WIN32, which -I THOUGHT- it seemed to do correctly. Results are similar: nothing obviously bad. HOWEVER warnings d) and e) all go away! That makes me think the compiler is not defining _WIN32_WINNT correctly during these tests. But -my- projects do specify _WIN32_WINNT=0x0600 and they get the ASIO compile errors. HEY! PROBLEM SOLVED: As suggested by others (and on the asio-users list), explicitly setting WINVER to match my explicit _WIN32_WINNT setting removed those compile errors! Yay! Mike This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Zachary Turner Sent: Friday, June 26, 2009 7:44 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compile errors inside boost::asio code I can'taffect.

<snip>

You might want to also double check your SDK version anyway like Christopher mentioned. If you're using a really old SDK version, it might give you other unforseen problems not related to boost. The latest platform sdk can always be found at microsoft's website.

I'm using whatever SDK comes with VS2008 (SP1 installed). Just building for "x64" platform. Nothing special. Mike This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Zachary Turner Sent: Friday, June 26, 2009 5:30 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compile errors inside boost::asio code I can'taffect.

On Fri, Jun 26, 2009 at 3:14 PM, wrote:

...

...

...

---------------- error C2664: 'QueueUserAPC' : cannot convert parameter 1 from 'void (__cdecl *)(ULONG)' to 'PAPCFUNC' D:\dev\3rdParty_x64\include\boost\asio\detail\win_thread.hpp    151

It appears to me that you can only get this error if you have defined WINVER to be something less than 0x0500, which means the software you are building is attempting to support a version of windows PRIOR to Windows 2000. Is this your intention? Try defining WINVER to be 0x0500 (if you want to run on Win2k and higher) and 0x0501 (if you want to run on WinXP+)

...

...

...

---------------- error C2664: 'GetQueuedCompletionStatus' : cannot convert

parameter 3 from

...

'DWORD *' to 'PULONG_PTR'

D:\dev\3rdParty_x64\include\boost\asio\detail\win_iocp_io_serv ice.hpp   142

...

...

...

---------------- error C2664: 'GetQueuedCompletionStatus' : cannot convert

parameter 3 from

...

'DWORD *' to 'PULONG_PTR'

D:\dev\3rdParty_x64\include\boost\asio\detail\win_iocp_io_serv ice.hpp   430

This could be related to the first issue. DWORD* and PULONG_PTR are supposed to be exactly the same type when compiling for x64 on recent operating systems. So it makes me think that the compiler thinks you're on a really old operating system. I would try this

#define WINVER 0x0501 #define _WIN32_WINNT 0x0501

either in your stdafx.h if you use precompiled header, or as a command line option if you don't.

On our 32-bit builds (where this problem does NOT occur) we have been using _WIN32_WINNT=0x0500 in an inherited .vsprops file. That's for both of these setups: - WinXP SP3 + VS2005, mostly for development, testing, etc - WindowsServer2003 + VS2005, generally our "production" environment On the 64-bit builds (where the problem DOES occur) I am using _WIN32_WINNT=0x0600 directly in the .vcproj files. That's on a WindowsServer2008 SP1, VS2008 setup. Either "windows.h" or "WinNT.h" says 0x0600 is "Longhorn", and it appears that WindowsServer2008 qualifies, based on what I thought I saw when I intentionally omitted _WIN32_WINNT and let the compiler pick the value. Maybe I'm wrong; I'll try to verify what happens if I don't specify anything for _WIN32_WINNT. If you think 0x0600 is a BAD value to use, let me know and I'll revert to 0x0501 all the way around. Thanks! Mike This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.

That took care of it. Thank you!

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Zachary Turner Sent: Friday, June 26, 2009 6:36 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compile errors inside boost::asio code I can'taffect.

...

On the 64-bit builds (where the problem DOES occur) I am using _WIN32_WINNT=0x0600 directly in the .vcproj files.   That's on a WindowsServer2008 SP1, VS2008 setup.  Either "windows.h" or "WinNT.h" says 0x0600 is "Longhorn", and it appears that WindowsServer2008 qualifies, based on what I

On Fri, Jun 26, 2009 at 5:47 PM, wrote: thought I saw when I intentionally omitted _WIN32_WINNT and let the compiler pick the value.  Maybe I'm wrong; I'll try to verify what happens if I don't specify anything for _WIN32_WINNT.

anything greater than or equal to 0x0500 is fine, but the asio header file is actually checking WINVER, not _WIN32_WINNT. WINVER is really just the 'legacy' version of _WIN32_WINNT but conceptually they are used for the same purpose. so i'm not sure why the header checks WINVER instead of _WIN32_WINNT, although there may be a good reason.

Anyway, long story short, leave the _WIN32_WINNT=0x0600 in, but additionally add WINVER=0x0600 and try that.

The reason this doesn't occur on 32 bit is because ULONG_PTR is a different type on 32 and 64-bits. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.