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