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

On Fri, Jun 26, 2009 at 7:26 PM, wrote:

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

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.