Notes |
|
(0033386)
|
Brad King
|
2013-06-26 14:07
(edited on: 2013-06-26 14:08) |
|
Which Fortran compiler are you using? I'm not sure all OS X Fortran compilers support these flags in their front-end, so we may need compiler-specific values for these flags.
|
|
|
(0033388)
|
Graham Markall
|
2013-06-26 15:05
|
|
I'm using:
$ gfortran --version
GNU Fortran (MacPorts gcc48 4.8.1_0) 4.8.1
A quick skim of Modules/Compiler suggests that the other supported OS X fortran compilers are Absoft and Intel - is this correct? I could look into what the correct options for these compilers are if it will make things easier for you. |
|
|
(0033389)
|
Brad King
|
2013-06-26 15:47
|
|
Re 0014249:0033388: A survey of compilers would be useful, thanks. We can put
set(CMAKE_Fortran_OSX_COMPATIBILITY_VERSION_FLAG "-compatibility_version ")
set(CMAKE_Fortran_OSX_CURRENT_VERSION_FLAG "-current_version ")
in Darwin.cmake but the concern is whether that will break existing builds if any compilers do not support the flags on this platform. Such compilers may need a -Wl, prefix on each flag, but we cannot do this in general because the underlying linker differs across versions of OS X and some want -Wl,-dylib_compatibility_version instead of -Wl,-compatibility_version. By using plain -compatibility_version to the compiler front-end where possible we allow the compiler to map it to the proper linker flag for the local system. |
|
|
(0033490)
|
Graham Markall
|
2013-07-06 13:56
|
|
Apologies for the delay in my reply - it took me a little while to setup trials
of all the Mac OS X Fortran compilers. This is what I found for each compiler
(all flags that I mention, I have tested):
GFortran:
Version string: GNU Fortran (MacPorts gcc48 4.8.1_0) 4.8.1
Flag to generate dynamic library: -shared
Flag for compatibility version: -compatibility_version x.y.z
Flag for current version: -current_version x.y.z
Absoft:
Version string: Absoft Pro Fortran 13.0.2
Flag to generate dynamic library: -shared
Flag for compatibility_version: -compatibility_version x.y.z
Flag for current_version: -current_version x.y.z (appears to be undocumented,
but works nontheless)
Intel:
Version string: ifort (IFORT) 13.0.3 20130606
Flag to generate dynamic library: -dynamic_lib
Flag for compatibility version: -compatibility_version x.y.z
FLag for current version: -current_version x.y.z
NAG:
The NAG compiler uses GCC for linking, so the flags are the same as those for
GCC, but are passed through to it using -Wl,<flag>
Version string: NAG Fortran Compiler Release 5.3.1(907)
Flag to generate dynamic library: -Wl,-shared
Flag for compatibility version: -Wl,-compatibility_version, -Wlx.y.z
Flag for current version: -Wl,-current_version, -Wlx.y.z
PGI:
The 64-bit PGI Fortran compiler does not support generating shared libraries.
I was unable to get the 32-bit version to produce a shared library: it appears
that PGI invokes libtool for linking dynamic libraries, and I could not seem
to get the PGI compiler to pass flags to it that it would accept on OS X 10.8.
Open64:
As far as I could ascertain, the Open64 compiler is not in general use on Mac
OS X - please correct me if I have come to the wrong conclusion, and I will
spend more time investigating Open64. |
|
|
(0033503)
|
Brad King
|
2013-07-08 10:02
|
|
Great, thanks for the survey. Try adding the appropriate settings to Darwin-Absoft-Fortran.cmake, Darwin-GNU-Fortran.cmake, Darwin-NAG-Fortran.cmake, etc. in Modules/Platform/. That should map the flags for each toolchain on the platform. |
|
|
(0033545)
|
Graham Markall
|
2013-07-16 06:02
|
|
I added the appropriate flag settings to Darwin-Absoft-Fortran.cmake and Darwin-GNU-Fortran.cmake. I had to create Darwin-Intel-Fortran.cmake to put these settings in with CMake 2.8.11.
As well as adding the appropriate settings to Darwin-NAG-Fortran.cmake, I had to add the following to succeed in building a shared library:
set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS "-Wl,-shared")
set(CMAKE_SHARED_LIBRARY_SONAME_Fortran_FLAG "-Wl,-install_name -Wl,")
set(CMAKE_Fortran_CREATE_SHARED_LIBRARY
"<CMAKE_Fortran_COMPILER> <LANGUAGE_COMPILE_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS> <LINK_FLAGS> -o <TARGET> <SONAME_FLAG><TARGET_INSTALLNAME_DIR><TARGET_SONAME> <OBJECTS> <LINK_LIBRARIES>")
The last line is because the space between <SONAME_FLAG> and <TARGET_INSTALLNAME_DIR> needed to be removed in order for the NAG compiler to parse the argument correctly. As far as I can see, it was probably not possible to build a shared library using the NAG compiler with CMake on Mac OS X before these additions.
After the addition of all these settings, the correct compatibility and current versions are set for generated libraries as expected - I have tested by building Lapack as shared libraries with each of the compilers.
Is there any more information that I should provide, or any further tests I should perform? Since I've already changed a few files, is it appropriate to make a patch/pull request at this stage? |
|
|
(0033547)
|
Brad King
|
2013-07-16 08:00
|
|
Re 0014249:0033545: Thanks! That all looks good. Please create a commit locally and use "git format-patch" to attach it here. |
|
|
(0033551)
|
Graham Markall
|
2013-07-16 08:57
|
|
I've now attached the patch. Most of the files I edited did not have a copyright header on, but I am only permitted to submit patches where the copyright is declared - I added the standard copyright header from other modules and used "2000-2011 Kitware, Inc." (as is in Copyright.txt) for the original copyright - I hope that this is OK, but please let me know if I should amend this and submit another patch. |
|
|
(0033553)
|
Brad King
|
2013-07-16 09:33
|
|
|
|
(0033554)
|
Graham Markall
|
2013-07-16 09:44
|
|
Many thanks for merging! Do you need me to do anything further for this issue? |
|
|
(0033555)
|
Brad King
|
2013-07-16 09:49
|
|
Re 0014249:0033554: This should be all set. Thanks again for the research and patch!
|
|
|
(0034647)
|
Robert Maynard
|
2013-12-02 08:51
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|