Hi Brad, Brad King wrote: > 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. > Thanks a lot. I opened up a bug report with the number 9615 for this issue. I think CMake should only use xiar in case the ipo option is present. We will use the ipo option in the near future, so simply setting XIAR="" would not work. > >> 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. > I tried this and it worked without problems.
Keep up the good work! Martin
_______________________________________________ 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
