<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Brad,<br>
<br>
Brad King wrote:
<blockquote cite="mid:4AC109DD.8010804@kitware.com" type="cite">
<pre wrap="">Hi Martin,
Thanks for trying the release candidate. It is helpful to get feedback
early in the release process.
Martin Apel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">However I found a few quirks in the first rc:
1. I have quite a lot of Fortran files in one of our projects. We use
the Intel Fortran 11 compiler to compile these.
When gathering the objects into a static library CMake 2.6 used to
call "ar" and "ranlib".
Now it seems to call the Intel tool xiar
</pre>
</blockquote>
<pre wrap=""><!---->
I believe CMake 2.6 used xiar for C and C++ static libraries, and this
fix was to make Fortran consistent with those.
</pre>
<blockquote type="cite">
<pre wrap="">which in turn calls xild and this step takes ages (about one minute).
</pre>
</blockquote>
<pre wrap=""><!---->
Wow. Perhaps it is looking for inter-procedural optimizations.
You can tell CMake not to use xiar by pretending that it is not available.
CMake uses find_program to locate the tool and stores the result in the
cache entry "XIAR". For a single build tree you can do
cmake . -DXIAR=
to erase the search result. If you want to stop it all the time, add
a line to tell CMake never to search for XIAR in the first place.
It must be done before the Fortran language is enabled because afterwards
the result of the search will already have been used. Try this:
cmake_minimum_required(VERSION 2.6)
set(XIAR "") # Never use Intel's xiar
project(FOO Fortran)
While this solution will work around the trouble for your project,
perhaps we should consider this a general bug since it was done for
C and C++ in CMake 2.6 already. According to the Intel user guide
we only really need to use xiar when the object files were compiled
with "-ipo" to enable inter-procedural optimization (is this correct?).
If you want to look at changing CMake's default behavior please open
a bug report for further discussion.
</pre>
</blockquote>
Thanks a lot. I opened up a bug report with the number 9615 for this
issue. I think CMake should<br>
only use xiar in case the ipo option is present. We will use the ipo
option in the near future, so<br>
simply setting XIAR="" would not work.<br>
<blockquote cite="mid:4AC109DD.8010804@kitware.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">2. Fortran-related as well: On Linux we used to link in the following
Intel Fortran libraries explicitly: ifcoremt, imf, irc.
With CMake 2.8 the following additional and unneeded (for us)
libraries can be found on the command line for the linker:
ifport, ifcore, svml, ipgo, intlc, irc_s. As we do not copy these
shared libraries to our runtime directory, the resulting
executables do not run. This means, that 2.8 is not
downward-compatible with 2.6 in this respect, so I would have to
code a version check into the CMakeLists.txt. Is this intended
behaviour?
</pre>
</blockquote>
<pre wrap=""><!---->
CMake 2.8 automatically detects the implicit runtime libraries used
by the compiler to create a binary for each language. When building
a link line for a mixed-language binary one of the languages is chosen
to invoke the linker, so it is known that its libraries will be implicit.
Implicit libraries for other languages are added explicitly.
Most of the time this all does nothing. A single-language binary will
always use its own linker so no extra libraries are needed. A mixed
C/C++ binary always uses the C++ linker and the C implicit libs are a
subset so nothing happens.
This should only be happening if the executable contains both C++
and Fortran code. While developing mixed-language C++/Fortran support
we considered the support in CMake 2.6 so immature that it was not
worth trying to be compatible. Our rationale is that it just plain
didn't work out of the box...every project would have to link to
implicit libraries explicitly for each platform anyway.
</pre>
<blockquote type="cite">
<pre wrap="">Or can I tell CMake not to add any additional compiler libraries?
</pre>
</blockquote>
<pre wrap=""><!---->
It adds libraries listed in CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES
that are not also listed in CMAKE_CXX_IMPLICIT_LINK_LIBRARIES.
Just add this line:
set(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)
It tells CMake to ignore any Fortran implicit libraries it detected.
Another approach is to erase unwanted libraries:
list(REMOVE_ITEM CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES
ifport ifcore svml ipgo intlc irc_s)
and stop explicitly linking known implicit libraries yourself. An
advantage of this approach is that things will work out of the box
by default for some user building your code. The extra work to
remove libraries is for your prebuilt distribution.
</pre>
</blockquote>
I tried this and it worked without problems.<br>
<br>
Keep up the good work!<br>
<br>
Martin<br>
</body>
</html>