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

Subject: Re: [Boost-users] Compile errors inside boost::asio code I can't affect.
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-06-26 20:43:44

On Fri, Jun 26, 2009 at 7:26 PM, <Michael.Broida_at_[hidden]> wrote:
> Response at bottom.  (Well, except for this line.)
>
>> -----Original Message-----
>> From: boost-users-bounces_at_[hidden]
>> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of
>> Steven Watanabe
>> Sent: Friday, June 26, 2009 4:30 PM
>> To: boost-users_at_[hidden]
>> Subject: Re: [Boost-users] Compile errors inside boost::asio
>> code I can't affect.
>>
>> AMDG
>>
>> Michael.Broida_at_[hidden] 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<Protocol,SocketService>::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.