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@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users