On Wed, Oct 7, 2009 at 11:12 AM, Justin Holewinski <shawmishrak@gmail.com> wrote:

I am trying to compile Boost 1.40 with the Intel C++ Compiler, Version 11.1, using CMake and I've encountered two issues so far.


First, on Windows, the Intel C++ Compiler follows Microsoft's naming convention.  The compiler executable is icl.exe, not icc.exe or icpc.exe.  Hence, the BoostConfig.cmake script fails to detect the Intel compiler on Windows because it tries to match the compiler name against icpc.exe.  The fix is trivial.  In BoostConfig.cmake, add an additional conditional on line 89:

elseif(CMAKE_CXX_COMPILER MATCHES "/icpc$" OR CMAKE_CXX_COMPILER MATCHES "/icpc.exe$" OR CMAKE_CXX_COMPILER MATCHES "/icl.exe$")

I'm not sure what impact this has on the build process other than applying the 'intel' branding to the generated libraries instead of 'unknown'.

Hi,

I can fix this in CVS, but might have a slightly better way.  Can you tell me what the value of CMAKE_CXX_COMPILER_ID is on Intel C++?
 



Second, the handling of inter-library dependencies appears to be broken (when using Intel C++), particularly the dependency between Boost.Wserialization and Boost.Serialization.  A different error is issued for different platforms.


Windows:

When building shared libraries, the Boost.Wserialization library attempts to link to the shared-library version of Boost.Serialization.  The link library is assumed to be in lib/ (as per Unix conventions), but link libraries for shared DLLs on Windows are placed in bin/.  This results in a CMake dependency error:

NMAKE : fatal error U1073: don't know how to make 'lib\boost_serialization-intel-mt-1.40.lib'

The correct dependency is instead 'bin\boost_serialization-intel-mt-1.40.lib'.

This is the second time today I've heard of people placing import libraries in bin folders.  Any reason why this is happening?

You could look into the Boost preprocessor definitions that disable auto linking and rely instead on CMake's target_link_libraries(). See the FindBoost docs for more information.

--
Philip Lowman