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