Re: [Boost-users] Building boost 1.34.1 with MSVC 8 (64-bit)

From: Eric Woodruff (eric.woodruff_at_[hidden])
Date: 2008-02-24 20:56:38

OK, to update this thread in case anyone was interested in it, my
previous problem was from a bad stlport include path. Now I just have a
few minor problems to work out that all look like they share the same
root cause:

 boost\iostreams\positioning.hpp(27) : error C2039: 'fpos_t' : is not a
member of '`global namespace''

 libs\regex\src\..\src\cregex.cpp(358) : error C2039: 'sprintf_s' : is
not a member of '`global namespace''

libs\regex\src\..\src\posix_api.cpp(168) : error C2039: 'sprintf_s' : is
not a member of '`global namespace''

libs\regex\src\..\src\wide_posix_api.cpp(161) : error C2039: 'wcscpy_s'
: is not a member of '`global namespace''

boost\iostreams\positioning.hpp(27) : error C2039: 'fpos_t' : is not a
member of '`global namespace''

Eric Woodruff wrote:
> I've been poking around in msvc.jam and I found the <setup> option is
> the moral equivalent to my previous MSCDir workaround. I configured it
> as cl : <setup>echo ; to essentially do nothing and this clearly
> invokes the compiler now:
> cl /Zm800 -nologo @"bin.v2\libs\serialization\build\msvc-8.0\debug\address-model-64\link-static\stdlib-stlport-5.1.5\stdlib-stlport-5.1.5\threading-multi\xml_grammar.obj.rsp"
> Now I have a different problem, but this problem occurs with msvc7.1
> 32-bit and msvc-8.0 64-bit:
> boost\spirit\core\non_terminal\impl\grammar.ipp(308) : error C2784: 'std::mem_fun_t<_R,_Ty> std::mem_fun(_R (__cdecl _Ty::* )(void))' : could not deduce template argument for 'T1 (__cdecl T2::* )(void)' from 'int (__cdecl boost::spirit::impl::grammar_helper_base<GrammarT>::* )(GrammarT *)'
>
> ...failed compile-c-c++ bin.v2\libs\serialization\build\msvc-8.0\debug\address-model-64\link-static\stdlib-stlport-5.1.5\stdlib-stlport-5.1.5\threading-multi\xml_grammar.obj...
>   
>
> If I build --without-serialization I get
>
>  boost\test\impl\exception_safety.ipp(453) : error C2039: 'isprint' : is not a member of 'std'
>   
> ...failed compile-c-c++ bin.v2\libs\test\build\msvc-8.0\release\address-model-64\asynch-exceptions-on\link-static\stdlib-stlport-5.1.5\stdlib-stlport-5.1.5\threading-multi\exception_safety.obj...
>
> If I build --without-test I get
> libs\date_time\src\gregorian\greg_month.cpp(126) : error C2665: 'std::locale::locale' : none of the 7 overloads could convert all the argument types
> And if I also build --without-date_time I get
>
> libs\filesystem\src\path.cpp(40) : error C2039: 'mbstate_t' : is not a member of 'std'
>
> ....failed compile-c-c++ bin.v2\libs\filesystem\build\msvc-8.0\debug\address-model-64\link-static\stdlib-stlport-5.1.5\stdlib-stlport-5.1.5\threading-multi\path.obj...
>   
>
> Eric Woodruff wrote:
>>> The first thing they say is that you should not use the path to 64-bit
>>> compiler in 'using'. That is likely to be the thing.
>>>   
>>
>> I only added the path after reading about the intel-9.1 problem in
>> hopes that that would fix my issue as well; originally I specified
>> nothing. I see that
>> http://boost.org/boost-build2/doc/html/bbv2/reference/tools.html#id2596373
>> is what you were referring to. I have now tried specifying the path
>> to the 32-bit compiler but still have the same problem.
>>
>> It may be significant to explicitly mention that the compiler is
>> actually the platform SDK and not an installation of Visual Studio --
>> but you could maybe tell that from the path to cl.exe.
>>
>> I now remember that to get 1_33_1 to build, I had to define MSCDir to
>> something so that the VCVARS bat wouldn't get loaded by boost, so I
>> set that variable to $MSCVER just so that it wouldn't be undefined. I
>> removed that workaround and still have this problem. I wonder how I
>> can tell if and where boost 1_34_1 is trying to be helpful and
>> configure my environment when it shouldn't.
>>> Also, you appear to be running nt build of bjam from cygwin; I'd recommend
>>> you use regular windows shell (which is not that bad these days).
>> Unfortunately, I'm stuck in this environment that I have no control over.
>>
>> Vladimir Prus wrote:
>>> Eric Woodruff wrote:
>>>
>>>   
>>>> Hello,
>>>>
>>>> I hope John Maddock is reading this as he had some knowledge of the
>>>> Intel compiler problem. Similar to the thread quoted below, I am getting
>>>> the  "Windows cannot open this file" dialog when trying to build boost
>>>> using VC8 as 64-bit. (Doesn't have /this/ problem when I don't set
>>>> address-model=64 or use the VC7.1 x86 compiler for 32-bit builds.) This
>>>> is with boost-jam-3.1.16-1-ntx86.
>>>>
>>>> I've tried adding the full path to cl.exe in user-config.jam without
>>>> success. For historical reasons, I am using an nmake Makefile (under a
>>>> Cygwin environment) to fit the boost build into an existing build
>>>> system. It essentially operates as follows:
>>>>
>>>> tar jxf boost_1_34_1.tar.bz2
>>>>
>>>> echo using msvc : 8.0 : "C:/WINDDK/3790.1830/bin/win64/x86/amd64/cl.exe" ; >
>>>> boost_1_34_1\tools\build\v2\user-config.jam
>>>>     
>>>
>>> You might want to read docs about 64-bit support, in Boost.Build documentation,
>>> available at boost.org/boost-build2.
>>>
>>> The first thing they say is that you should not use the path to 64-bit
>>> compiler in 'using'. That is likely to be the thing.
>>>
>>> Also, you appear to be running nt build of bjam from cygwin; I'd recommend
>>> you use regular windows shell (which is not that bad these days).
>>>
>>> - Volodya
>>>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users