Boost logo

Boost Users :

From: Eric Woodruff (eric.woodruff_at_[hidden])
Date: 2008-02-24 18:21:04


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 list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net