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: Michael.Broida_at_[hidden]
Date: 2009-06-26 20:26:00

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

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.