Scalapack dependency finder bug

[GuillaumeQuenneville]

Describe the bug

  File "/home/guillaume/.pyenv/versions/3.10.2/lib/python3.10/site-packages/mesonbuild/dependencies/pkgconfig.py", line 102, in __init__
    self._set_libs()
  File "/home/guillaume/.pyenv/versions/3.10.2/lib/python3.10/site-packages/mesonbuild/dependencies/scalapack.py", line 113, in _set_libs
    libdir = self.__mklroot / 'lib/intel64'
TypeError: unsupported operand type(s) for /: 'NoneType' and 'str'

meson.build:49:0: ERROR: Unhandled python exception

    This is a Meson bug and should be reported!
make: *** [Makefile:38: configure] Error 2

I get the above (tail of) error when compiling with a program with a dependency on scalapack. I was able to reproduce this in both 0.57 and 0.64.1
I recently installed the intel toolchain on my computer. I also use the gcc toolchain on the same computer. I have a specific file to source which is not in my .rc file when i want to use the intel toolchain.

If I do not source the oneapi toolchain, the scalapack dependency finder still adds the intel scalapack to the candidates and tries to find it. Since the toolchain is not sourced, __mklroot is ends up being None. And the MKL dependencies are tried first in the candidates.
see
https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/scalapack.py#L38

Putting the regular pkgconfig candidate.append before the mkl candidate.append fixes the issue and it finds the gcc scalapack. Sourcing the oneapi toolchain also fixes the error (but it find the mkl scalapack).

I'd be happy to submit a pr with a fix. Let me know if you have a preferred method of addressing this.

To Reproduce
(Ubuntu 22.04)

• install a gcc compiled scalapack with a pkgconfig file
• Install intel toolchain
• create program with a scalapack dependency
• Do not source /opt/intel/oneapi/setvars.sh
• __mklroot is not set because oneapi is not sourced
• gcc scalapack pkgconfig never tried because of uncaught exception

Expected behavior

system parameters

❯ meson --version
0.64.1
❯ ninja --version
1.10.1
❯ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"
❯ python --version
Python 3.10.2

[scivision]

I put myself as assignee since I implemented this functionality. However anyone feel free to look at this if you want.

[eli-schwartz]

Sounds like if mklroot isn't defined we should immediately return not-found and proceed to the next candidate?

[GuillaumeQuenneville]

I think we should do that.

The other question would be whether we change the precedence. The issue I see is the gcc scalapack is being found because of the PKG_CONFIG_PATH environment variable (in this case) which is a pretty explicit setting. So a user who has the intel toolchain sourced and PKG_CONFIG_PATH set might be surprised if it finds the MKL one which is automagically searched for first.

Maybe the precedence if possible could be

• PKG_CONFIG_PATH environment variable
• SOME_EXPLICIT_MKL environment variable
• MKL default search paths
• PKG_CONFIG default search paths

or some permutation of that. I get the feeling like this is a problem that can have a lot of edge cases and no best answer though...

[scivision]

I tried this and it didn't reproduce the error on my system. However I think it's good to handle this edge case. @GuillaumeQuenneville would be nice to try whatever PR you'd like to make.

I put on my PKG_CONFIG_PATH a scalapack.pc from GCC, while MKLROOT env var was not defined, despite having MKL installed.

[mgorny]

I'm going to take a look at this… since it's getting triggered in #14773 when I add mkl to deps.

Overall, the problem seems to be that PkgConfigDependency.__init__() calls _set_cargs() and _set_libs() — but these functions seem to assume that they would be only called when self.__mklroot is not None, i.e. when the lookup succeeded.