Hello, on the host with dev-lang/path64[fortran] installed lapacke-reference-3.4.2 tries to use it via some magick instead of gfortran: -- Check for working Fortran compiler: /usr/lib64/path64/bin/pathf95 -- Check for working Fortran compiler: /usr/lib64/path64/bin/pathf95 -- broken CMake Error at /usr/share/cmake/Modules/CMakeTestFortranCompiler.cmake:54 (message): The Fortran compiler "/usr/lib64/path64/bin/pathf95" is not able to compile Compilation failure is due to gcc-spefic flags into FFLAGS/FCFLAGS and this can be fixed on my side. But I can't understand why pathf95 is used in the first place: I haven't forced FC globally and all other packages use gfortran on this host.
Created attachment 359836 [details] emerge --info
Created attachment 359838 [details] build.log
Created attachment 359840 [details] environment
Created attachment 359842 [details] eclass-debug.log
In the cmake module CMakeDetermineFortranCompiler.cmake pathf95 is tested before gfortran: set(CMAKE_Fortran_COMPILER_LIST ifort ifc af95 af90 efc f95 pathf2003 pathf95 pgf95 pgfortran lf95 xlf95 fort gfortran gfortran-4 g95 f90 pathf90 pgf90 xlf90 epcf90 fort77 frt pgf77 xlf fl32 af77 g77 f77 ) If no compiler is set by FC. Not sure what to do. We could change the order in cmake but that's clearly invasive. But lapacke should be fixed (upstream) to be more graceful about other compilers and pathf95 in particular.
IMO the best way will be to notify upstream and to alter cmake module before this issue is resolved upstream.
Did you set FC somewhere?
He said specifically that he didn't set FC in the original post. Sure that would solve the problem. For a value of solve.
We could provide an over-ride of the CMAKE_Fortran_COMPILER_LIST variable in gentoo_common_config.cmake or as part of gentoo_rules.cmake. We would put gfortran as the first choice. It would still be overidden if FC is set but it would make it default to gfortran otherwise. Of course we could just patch cmake to behave that way. The question is: do we want to make sure that gfortran is the default Fortran compiler for cmake? It wouldn't prevent an override by setting FC.
Setting FC=gfortran solves this issue, however this will require all users with pathscale installed and FC?FLAGS with gcc-specific options to either set FC or to configure FCFLAGS for pathf95. CMAKE_Fortran_COMPILER_LIST override sounds like a good solution for me, since user may want to use other compilers than gfortran for better performance.
Also auto-dependency on ifc if installed.
could anyone report upstream? they've been pretty responsive so far.
I'm not really sure what to report: ask them to check gfortran prior to any other Fortran compiler? They will likely argue that icc or path64 give better performance and should be preferred therefore. And yes, I hit this issue again :/
(In reply to Andrew Savchenko from comment #13) > I'm not really sure what to report: ask them to check gfortran prior to any > other Fortran compiler? They will likely argue that icc or path64 give > better performance and should be preferred therefore. > > And yes, I hit this issue again :/ Can we ask them to respect the compiler passed as FC rather than using the first available on their list?
Hmm, file CMakeDetermineFortranCompiler.cmake is no longer present in 3.5.0...
(In reply to Andrew Savchenko from comment #15) > Hmm, file CMakeDetermineFortranCompiler.cmake is no longer present in > 3.5.0... What do they use? Easiest would be to leverage cmake own functions to find compilers and these respect CC, CXX, FC and so on if I am not mistaken. I may have a closer look later if you need a second pair of eyes.
(In reply to Francois Bissey from comment #16) > (In reply to Andrew Savchenko from comment #15) > > Hmm, file CMakeDetermineFortranCompiler.cmake is no longer present in > > 3.5.0... > > What do they use? Easiest would be to leverage cmake own functions to find > compilers and these respect CC, CXX, FC and so on if I am not mistaken. I > may have a closer look later if you need a second pair of eyes. Oh, I finally get it. They use cmake own function to determine fortran compiler, this is CMakeDetermineFortranCompiler.cmake mentioned above, but it belongs to cmake and is located at /usr/share/cmake/Modules, so I just searched in a wrong place earlier. So this is cleanly cmake bug and has nothing to do with lapacke itself. Should we report bug for cmake? In Gentoo or upstream? If upstream, should we test 3.1.0 first? (released at 17.12.2014)
If it is a cmake bug, other packages will be affected. lapack-reference for example. Can you cross check that it is the case. If so it is probably a problem for upstream but we should have a bug in gentoo to find a work around or get a fix from upstream in if it will take a while to release. I will definitely have a closer look later today as this is very suspicious. By the way which version of cmake are you using?
Hmm, from /usr/share/cmake/Modules/CMakeDetermineFortranCompiler.cmake: # The order is 95 or newer compilers first, then 90, # then 77 or older compilers, gnu is always last in the group, # so if you paid for a compiler it is picked by default. I don't agree with them (PathScale is also free to start with), but with this attitude I doubt cmake upstream will fix anything. While not add something like: SET (CMAKE_Fortran_COMPILER $(tc-getFC)) to cmake-utils.eclass? This should fix everything.
(In reply to Francois Bissey from comment #18) > If it is a cmake bug, other packages will be affected. lapack-reference for > example. Can you cross check that it is the case. If so it is probably a > problem for upstream but we should have a bug in gentoo to find a work > around or get a fix from upstream in if it will take a while to release. Oh, good hint. Looks like I found a reason of different behaviour between lapack-reference and lapacke-reference: the former sets FC variable, the latter does not. The former does this by an indirect fortran2-pkg-setup call, while the latter lacks it. I'll check if this helps in a while. > I will definitely have a closer look later today as this is very suspicious. > By the way which version of cmake are you using? The latest from tree: cmake-3.0.2.
(In reply to Andrew Savchenko from comment #20) > Oh, good hint. Looks like I found a reason of different behaviour between > lapack-reference and lapacke-reference: the former sets FC variable, the > latter does not. The former does this by an indirect fortran2-pkg-setup > call, while the latter lacks it. I'll check if this helps in a while. using fortran-2_pkg_setup doesn't help, but fixing cmake-utils.eclass helps. See patch below.
Created attachment 393128 [details, diff] cmake-utils.eclass.diff Ensure that FC is set properly. The same way it is done for CC and CXX, I see no reason why Fortran should be omitted.
(In reply to Andrew Savchenko from comment #22) > Created attachment 393128 [details, diff] [details, diff] > cmake-utils.eclass.diff > > Ensure that FC is set properly. > > The same way it is done for CC and CXX, I see no reason why Fortran should > be omitted. @kde: could you please merge this patch in cmake-utils.eclass!
(In reply to Andrew Savchenko from comment #19) > Hmm, from /usr/share/cmake/Modules/CMakeDetermineFortranCompiler.cmake: > > # The order is 95 or newer compilers first, then 90, > # then 77 or older compilers, gnu is always last in the group, > # so if you paid for a compiler it is picked by default. > > I don't agree with them (PathScale is also free to start with), but with > this attitude I doubt cmake upstream will fix anything. > > While not add something like: > > SET (CMAKE_Fortran_COMPILER $(tc-getFC)) > > to cmake-utils.eclass? > This should fix everything. There are other problems with the order but I won't dwell on them. Yes, if it is done for the other languages it is a good idea. Although I am surprised that just setting FC doesn't work, that is definitely strange, there may be a bug somewhere specifically in lapack-reference. For the record upstream cmake doesn't like people using CMAKE_$lang_COMPILER. This can be lost if you do several passes as when you use ccmake but with plain cmake which does everything in one pass, like we do, that's OK.
(In reply to Francois Bissey from comment #24) > Yes, if it is done for the other languages it is a good idea. Although I am > surprised that just setting FC doesn't work As I mentioned above in comment 10 it works. But then FC should be set for every package using cmake and fortran, so to guarantee this and to make sure FC is set to a proper value I proposed patch for cmake-utils.eclass.
(In reply to Andrew Savchenko from comment #25) > (In reply to Francois Bissey from comment #24) > > Yes, if it is done for the other languages it is a good idea. Although I am > > surprised that just setting FC doesn't work > > As I mentioned above in comment 10 it works. But then FC should be set for > every package using cmake and fortran, so to guarantee this and to make sure > FC is set to a proper value I proposed patch for cmake-utils.eclass. Sorry I misread your comment about FC. Glad I had.
@kde: any progress here?
Do we need to set CMAKE_Fortran_COMPILE_OBJECT too, how we do for C and CXX?
I'm not sure here, it works for me either way. Probably we should, I see no harm in that, but we will have consistency.
In any case, if it works for you, please commit what you think is best.
OK, as devmanual requires, I just mailed patch and its description to gentoo-dev ML.
In tree now.