Hi Martin,
Thanks for trying the release candidate. It is helpful to get feedback
early in the release process.
Martin Apel wrote:
> 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
I believe CMake 2.6 used xiar for C and C++ static libraries, and this
fix was to make Fortran consistent with those.
> which in turn calls xild and this step takes ages (about one minute).
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.
> 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?
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.
> Or can I tell CMake not to add any additional compiler libraries?
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.
-Brad
_______________________________________________
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
