Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 486626 - [science overlay] sci-libs/lapacke-reference-3.4.2 has automagic dependency on pathf95 (fortran compiler from dev-lang/path64[fortran])
Summary: [science overlay] sci-libs/lapacke-reference-3.4.2 has automagic dependency o...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-01 03:25 UTC by Andrew Savchenko
Modified: 2015-02-18 06:19 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge.info,7.84 KB, text/plain)
2013-10-01 03:26 UTC, Andrew Savchenko
Details
build.log (build.log,5.74 KB, text/x-log)
2013-10-01 03:26 UTC, Andrew Savchenko
Details
environment (environment,117.98 KB, text/plain)
2013-10-01 03:26 UTC, Andrew Savchenko
Details
eclass-debug.log (eclass-debug.log,3.43 KB, text/x-log)
2013-10-01 03:26 UTC, Andrew Savchenko
Details
cmake-utils.eclass.diff (cmake-utils.eclass.diff,384 bytes, patch)
2015-01-04 04:15 UTC, Andrew Savchenko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Savchenko gentoo-dev 2013-10-01 03:25:08 UTC
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.
Comment 1 Andrew Savchenko gentoo-dev 2013-10-01 03:26:01 UTC
Created attachment 359836 [details]
emerge --info
Comment 2 Andrew Savchenko gentoo-dev 2013-10-01 03:26:15 UTC
Created attachment 359838 [details]
build.log
Comment 3 Andrew Savchenko gentoo-dev 2013-10-01 03:26:33 UTC
Created attachment 359840 [details]
environment
Comment 4 Andrew Savchenko gentoo-dev 2013-10-01 03:26:56 UTC
Created attachment 359842 [details]
eclass-debug.log
Comment 5 François Bissey 2013-10-02 20:34:59 UTC
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.
Comment 6 Andrew Savchenko gentoo-dev 2013-10-03 03:42:30 UTC
IMO the best way will be to notify upstream and to alter cmake module before this issue is resolved upstream.
Comment 7 Justin Lecher (RETIRED) gentoo-dev 2013-10-03 05:36:56 UTC
Did you set FC somewhere?
Comment 8 François Bissey 2013-10-03 07:24:10 UTC
He said specifically that he didn't set FC in the original post. Sure that would solve the problem. For a value of solve.
Comment 9 François Bissey 2013-10-04 10:40:09 UTC
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.
Comment 10 Andrew Savchenko gentoo-dev 2013-10-04 18:19:59 UTC
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.
Comment 11 Christoph Junghans (RETIRED) gentoo-dev 2014-06-06 15:51:55 UTC
Also auto-dependency on ifc if installed.
Comment 12 Sébastien Fabbro (RETIRED) gentoo-dev 2014-06-10 15:47:24 UTC
could anyone report upstream? they've been pretty responsive  so far.
Comment 13 Andrew Savchenko gentoo-dev 2015-01-02 21:05:13 UTC
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 :/
Comment 14 François Bissey 2015-01-02 23:32:46 UTC
(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?
Comment 15 Andrew Savchenko gentoo-dev 2015-01-03 00:04:20 UTC
Hmm, file CMakeDetermineFortranCompiler.cmake is no longer present in 3.5.0...
Comment 16 François Bissey 2015-01-03 00:23:59 UTC
(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.
Comment 17 Andrew Savchenko gentoo-dev 2015-01-04 03:31:38 UTC
(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)
Comment 18 François Bissey 2015-01-04 03:44:21 UTC
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?
Comment 19 Andrew Savchenko gentoo-dev 2015-01-04 03:46:18 UTC
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.
Comment 20 Andrew Savchenko gentoo-dev 2015-01-04 03:59:20 UTC
(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.
Comment 21 Andrew Savchenko gentoo-dev 2015-01-04 04:14:31 UTC
(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.
Comment 22 Andrew Savchenko gentoo-dev 2015-01-04 04:15:54 UTC
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.
Comment 23 Christoph Junghans (RETIRED) gentoo-dev 2015-01-04 05:19:32 UTC
(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!
Comment 24 François Bissey 2015-01-04 05:30:10 UTC
(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.
Comment 25 Andrew Savchenko gentoo-dev 2015-01-04 13:18:01 UTC
(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.
Comment 26 François Bissey 2015-01-04 19:22:30 UTC
(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.
Comment 27 Andrew Savchenko gentoo-dev 2015-02-11 04:33:28 UTC
@kde: any progress here?
Comment 28 Michael Palimaka (kensington) gentoo-dev 2015-02-11 12:50:38 UTC
Do we need to set CMAKE_Fortran_COMPILE_OBJECT too, how we do for C and CXX?
Comment 29 Andrew Savchenko gentoo-dev 2015-02-11 13:37:13 UTC
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.
Comment 30 Michael Palimaka (kensington) gentoo-dev 2015-02-11 13:47:05 UTC
In any case, if it works for you, please commit what you think is best.
Comment 31 Andrew Savchenko gentoo-dev 2015-02-11 18:15:56 UTC
OK, as devmanual requires, I just mailed patch and its description to gentoo-dev ML.
Comment 32 Andrew Savchenko gentoo-dev 2015-02-18 06:19:59 UTC
In tree now.