Re: [Boost-users] Building Boost 1.48 using Intel compiler

Am 17.11.2011 23:52, schrieb Kim:

First time posting to a mailing list, sorry if I've messed something up.

I'm trying to build Boost 1.48 using Intel XE 12.1 and when running bjam it brings up "Windows can't open this file" for each file.

I tried to adapt instructions from here:

http://software.intel.com/en-us/articles/building-boost-with-intel-c/

I added the following to user-config.jam: using intel-win : 12.1 : "C:/Program Files (x86)/Intel/Composer XE/bin/ia32/icl.exe" : intel "C:/Program Files (x86)/Intel/Composer XE/bin/iclvars_ia32.bat" ;

I tried building with the following command:

C:\Users\blanked\Desktop\boost_1_48_0>bjam --toolset="intel" "-sINTEL_PATH=C :\Program Files (x86)\Intel\Composer XE\bin\ia32\" "-sINTEL_BASE_MSVC_TOOLSET=vc -10_0" "-sINTEL_VERSION=12.1"

[...]

It works for me if I setup the environment variables first by executing iclvars.bat. After that bjam toolset=intel can be used to compile Boost without additional settings. Unfortunately, two problems remain. The first one is a compilation error related to Boost.PropertyTree: .\boost/property_tree/detail/ptree_implementation.hpp(52): error #501: argument of type "const std::string std::_Pair_basestd::string>>::*" is incompatible with template parameter of type "const std::string std::pairstd::string>>::*" &value_type::first>, ^ detected during: instantiation of class "boost::property_tree::basic_ptree::subs [with Key=std::string, Data=std::string, KeyCompare=std::lessstd::string]" at line 101 instantiation of class "boost::property_tree::basic_ptree::const_iterator [with Key=std::string, Data=std::string, KeyCompare=std::lessstd::string]" at line 266 of ".\boost/foreach.hpp" instantiation of class "boost::foreach_detail_::auto_any<T> [with T=boost::property_tree::basic_ptreestd::string>::const_iterator]" at line 37 of "libs\graph\src\graphml.cpp" The second one is related to Boost.Locale: bjam is unable to detect the Windows version of ICU. This is due the fact, that bjam tries to locate icudata.lib and icui18n.lib instead of icudt.lib and icuin.lib respectively, which are the Windows names of the former libraries.