Re: [Boost-users] Compile errors inside boost::asio code I can't affect.

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.