Building boost 1.34.1 with MSVC 8 (64-bit)
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 echo using stlport : 5.1.5 : c:\cygwin\home\ewoodruff\build\trunk\winnt\amd64\x64-WINNT\TOOLS\usr\include\stlport c:\cygwin\home\ewoodruff\build\trunk\winnt\amd64\x64-WINNT\TOOLS\usr\lib ; >> boost_1_34_1\tools\build\v2\user-config.jam sed -ie 's,\\\\,/,g' boost_1_34_1\tools\build\v2\user-config.jam cd boost_1_34_1 && "c:\cygwin\home\ewoodruff\build\trunk\winnt\amd64\boost\boost-jam-3.1.16-1-ntx86\bjam.exe" "-q" "--toolset=msvc-8.0" "--prefix=c:\cygwin\home\ewoodruff\build\trunk\winnt\amd64\x64-WINNT\TOOLS" "runtime-link=shared" "link=static" "threading=multi" "stdlib=stlport-5.1.5" "address-model=64" "--without-python" "--without-wave" stage install Once the first directory leaf is created is when the .rcp file tries to get run. Here's the content of that file: $ cat 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/basic_archive.obj.rsp "libs\serialization\src\basic_archive.cpp" -Fo"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\basic_archive.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /favor:blend /wd4675 /EHs /Gy -c -DBOOST_ALL_NO_LIB=1 -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 "-I." "-Ic:\cygwin\home\ewoodruff\build\trunk\winnt\amd64\x64-WINNT\TOOLS\usr\include\stlport" I'm also curious, is stdlib-stlport-5.1.5 supposed to be in the path twice? Thanks in advance, Eric
*Subject:* [Boost-users] Building boost 1.34.1
*From:* James Emerton
*Date:* 2007-08-31 18:08:46
------------------------------------------------------------------------ I'm having difficulties building boost 1.34.1 using the intel toolchain. Once bjam tries to invoke the compiler, I get the "Windows cannot open this file" dialog, where the file is an .obj.rsp file.
It would appear that perhaps the compiler itself is not making it into the command line, thus causing the system to try executing the .rsp file directly. I am not having this problem if I use the msvc toolchain.
Command to invoke the build: bjam --toolset=intel-9.1 Compiler: Intel(R) C++ Compiler for 32-bit applications, Version 9.1 Build 20060519Z bjam: Boost.Jam Version 3.1.14. OS=NT.
Some environment variables:
ICPP_COMPILER91=C:\Program Files\Intel\Compiler\C++\9.1 INTEL_BASE_MSVC_TOOLSET=vc-7_1 INTEL_LICENSE_FILE=C:\Program Files\Common Files\Intel\Licenses INTEL_PATH=C:\Program Files\Intel\Compiler\C++\9.1\Ia32 INTEL_SHARED=C:\Program Files\Common Files\Intel\Shared Files
I've run the iclvars batch script, icl.exe is on the path, and I've used this environment to build boost 1.33 successfully. I've tried various debug levels of bjam, and I haven't seen anything that makes a problem obvious to me.
Thanks James _______________________________________________ Boost-users mailing list Boost-<email removed> http://lists.boost.org/mailman/listinfo.cgi/boost-users
------------------------------------------------------------------------
*From:* John Maddock
*Date:* 2007-08-31 19:17:38
------------------------------------------------------------------------ James Emerton wrote: /> I'm having difficulties building boost 1.34.1 using the intel/ /> toolchain. Once bjam tries to invoke the compiler, I get the "Windows/ /> cannot open this file" dialog, where the file is an .obj.rsp file./ />/ /> It would appear that perhaps the compiler itself is not making it into/ /> the command line, thus causing the system to try executing the .rsp/ /> file directly. I am not having this problem if I use the msvc/ /> toolchain./
Yep, it's bug report already: http://zigzag.cs.msu.su/boost.build/ticket/137
It does work if you add an entry for intel to a user-config.jam in your HOME directory, mine looks like:
using intel-win : 9.1 : "c:/program files/intel/compiler/c++/9.1/ia32/bin/icl.exe" ; using intel-win : 10.0 : "c:/program files/intel/compiler/c++/10.0.025/ia32/bin/icl.exe" ; using intel-win : 8.1 : "c:/program files/intel/cpp/compiler80/ia32/bin/icl.exe" ; #using intel-win : 7 : "c:/program files/intel/cpp/compiler70/ia32/bin/icl.exe" ; #using intel-win : 6 : "c:/program files/intel/cpp/compiler60/ia32/bin/icl.exe" ;
See the Boost.Build docs for more info on setting this up. And of course in most cases you can always build the source from your IDE should you prefer :-)
HTH, John.
_______________________________________________ Boost-users mailing list Boost-<email removed> http://lists.boost.org/mailman/listinfo.cgi/boost-users
Eric Woodruff wrote:
Hello,
I hope John Maddock is reading this as he had some knowledge of the Intel compiler problem.
Yes but that doesn't mean I have a solution !
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
I'm not sure, but I don't think that is a location where bjam will search for and find user-config.jam ? See http://boost.org/boost-build2/doc/html/bbv2/reference.html#bbv2.reference.in... for the paths searched. Having said that STLport appears to be getting included, so <shrug>, not sure :-( John.
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
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
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
participants (3)
-
Eric Woodruff -
John Maddock -
Vladimir Prus