[Boost-users] Building boost 1.34.1 with MSVC 8 (64-bit)

[Eric Woodruff]

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
  

[John Maddock]

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.init.config
for the paths searched.

Having said that STLport appears to be getting included, so <shrug>, not
sure :-(

John.

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Vladimir Prus]

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

[Eric Woodruff]

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.

[Eric Woodruff]

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...