[CMake] Intel compilers

[Leif Walsh]

On 11 May, 2012, at 5:12 PM, Mohammad Mirzadeh wrote:

> > You generally need to set CC, CXX, LD, and AR.  I found that in some cases
> > even that didn't work.  I use this:
> 
> > option(INTEL_CC "Use the Intel compiler." OFF)
> 
> > if (INTEL_CC)
> > find_program(CMAKE_C_COMPILER NAMES icc)
> > find_program(CMAKE_CXX_COMPILER NAMES icpc)
> > find_program(CMAKE_AR NAMES xiar)
> > find_program(CMAKE_LINKER NAMES xild)
> 
> > if (CMAKE_C_COMPILER MATCHES CMAKE_C_COMPILER-NOTFOUND OR
> >     CMAKE_CXX_COMPILER MATCHES CMAKE_CXX_COMPILER-NOTFOUND OR
> >     CMAKE_AR MATCHES CMAKE_AR-NOTFOUND OR
> >     CMAKE_LINKER MATCHES CMAKE_LINKER-NOTFOUND)
> >   message(FATAL_ERROR "Cannot find Intel compiler.  You may need to run `. /opt/intel/bin/compilervars.sh intel64'")
> > endif ()
> > endif (INTEL_CC)
> 
> When I run ccmake -DINTEL_CC:BOOL=ON path/to/CMakeLists.txt, It does not pick up intel compilers and I'm stuck with gcc. If I do CC=icc CXX=icpc ccmake -DINTEL_CC:BOOL=ON path/to/CMakeLists.txt it can correctly find all the libraries and prints:
> 
I forgot to mention that this must happen before you call project(), because that is where cmake detects a bunch of things about your compiler.

> CMake Warning at CMakeLists.txt:10 (ADD_EXECUTABLE):
>    Cannot generate a safe linker search path for target cmTryCompileExec
>    because files in some directories may conflict with libraries in implicit
>    directories:
> 
>      link library [libimf.so] in /opt/apps/intel/10.1/cc/lib may be hidden by files in:
>        /opt/apps/intel/10.1/fc/lib
>      link library [libsvml.so] in /opt/apps/intel/10.1/cc/lib may be hidden by files in:
>        /opt/apps/intel/10.1/fc/lib
>      link library [libipgo.a] in /opt/apps/intel/10.1/cc/lib may be hidden by files in:
>        /opt/apps/intel/10.1/fc/lib
>      link library [libirc.so] in /opt/apps/intel/10.1/cc/lib may be hidden by files in:
>        /opt/apps/intel/10.1/fc/lib
>      link library [libirc_s.a] in /opt/apps/intel/10.1/cc/lib may be hidden by files in:
>        /opt/apps/intel/10.1/fc/lib
> 
>    Some of these libraries may not be found correctly.
> 
> Do I need to fix my LD_LIBRARY_PATH? right now it seems echo $LD_LIBRARY_PATH says: /opt/apps/intel/10.1/cc/lib is in path (along with other stuff of course). 

possibly, I don't know what fc/lib is, maybe fortran libraries?
> 
> > What references is it missing?  I'm willing to bet it's having trouble
> > finding the intel libraries, maybe irc or imf.  Make sure you have sourced
> > the compiler vars script before running cmake.  Maybe if you tell me what
> > references it can't find I can help better.
> 
> Its not system libraries its missing, it seems to be some of my own. Problem is when I turn on ipo, apparently compiler requires all the other symbols from all the functions that are called when building each library. Normally I do not need them until linking to my executable so when I omit ipo, there is no issue. Also, if if I use ip, which does the same sort of optimization but restricts to the current file, I do not get linking issues.

yeah I think you need to call target_link_libraries(foo bar) if foo depends on symbols in bar, regardless of whether one or both is static
> 
> > I guess you have some static libraries that need symbols from each other
> > and you have not added all necessary target_link_libraries() calls.
> > Without this the linking order is obviously not right.
> 
> Yes that seems to be the case. So normally, without ipo, there is no linking problems since all the actual linking happens when building the executable at which point I link to all required libraries. Question is, when you are building a static libraries, do you require all the linking symbols at that point or you could relax until linking the executable? This brings us to my last question. Is this fundamentally different when working object files? I do not think you would need symbols when working with object files until you initiate the linking. That's why I asked if I could bypass the static libraries and just make the objects instead.

Here is what I do:

each library I build has a static and shared version (libfoo and libfoo_static).  All the programs that test libfoo link with the shared one, so you can do ipo when building the shared library and then you don't need to do it again when you link the executable.

I ship a shared library libfoobar.so, when I build it, I link with libfoo_static.a and it does optimization between the source files that make up libfoobar.so and the already built libfoo_static.a.  So that's basically whole program optimization, but since I still build libfoo.so, my tests can link with that and not have a gigantic headache as icc tries to do whole program optimization on pretty much my whole source tree once for each test at link time.

> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

-- 
Cheers,
Leif