cppyy conda package 2.4.0 breaks numba

[rdemaria]

I am observing this on a fresh installation of miniconda:

https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
sh ~/Miniconda3-latest-Linux-x86_64.sh -b -p ~/.miniconda3
conda install -y mamba
mamba install -y numba
python -c 'import numba; print(numba.jit(lambda :42)())'

I get 42, but as soon as I

mamba install -y cppyy
python -c 'import numba; print(numba.jit(lambda :42)())'

I get

(Re-)building pre-compiled headers (options: -O2 -march=native); this may take a minute ...
Segmentation fault (core dumped)

I guess the reason is that conda pulls gcc_linux-64, gxx_linux-64, libllvm9 and somehow numba is not fetching the right libraries anymore, but I am not sure how to solve this

[rdemaria]

Using stock pip install instead I get:

...site-packages/numba/core/dispatcher.py:289: UserWarning: Numba extension module 'cppyy.numba_ext' failed to load due to 'ImportError(.../site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so: undefined symbol: _ZSt28__throw_bad_array_new_lengthv)'.
  entrypoints.init_all()

but at least numba does not crash...

[rdemaria]

Indeed cppyy 2.3.1 is ok on conda.

[wlav]

Difference between 2.3.1 and 2.4.0 behavior is clear: the former does not sport cppyy/numba_ext.py.

I'm a bit surprised that the numba extension hooks pull in all extension hooks, regardless as to whether the module providing the hooks has already been loaded as well. That seems genuine overkill: cppyy/numba_ext.py imports cppyy and irrespective of crashing, that's kindof heavy unless you actually use it. I'll see first whether that can be changed, otherwise will more likely disable the extension hooks.

As for crashing in the conda env, not sure (I'm not the dev behind that). Does the installation order matter?

[rdemaria]

No it doesn't. It is not clear to what segfaults in numba. gdb showed this:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007fffcdb3608d in llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool) () from .../site-packages/cppyy_backend/lib/../../../../libLLVM-9.so

It looks like that when importing cppyy/numba_ext.py, numba picks libLLVM-9.so in the cppyy_backend, rather than libLLVM-10.so

[wlav]

cppyy_backend should not link with libLLVM, as that exposes symbols. I guess that's what the conda build does differently from the PyPI package, with the latter failing due to differences in libstdc++ in the conda environment. Anyway, if true, it will not be possible to use cppyy + Numba in a conda environment, only in a pip one.

[rdemaria]

Indeed, installing cppyy via pip, solves the problem.

[saraedum]

cppyy_backend should not link with libLLVM, as that exposes symbols.

Could you elaborate on what is happening and what should happen instead?

[wlav]

Both Numba and cppyy use LLVM (in a future iteration, I hope to have an llvmlite interface on top of Cling, such that cppyy users only have one, which would allow for inlining C++ into Numba Python traces), but different versions. So if one sees symbols from the other's LLVM, the interfaces are often the same, but the semantics differ and the code goes plink.

In the PyPI build, LLVM symbols are not exposed, b/c the linking of LLVM is statically into libCling with visibility=hidden (modulo a few things that need to be exposed, e.g. handling of cling::Value and RTTI & memory handling on Windows). The upshot is that with that approach, there can be 2 LLVM runtimes in the same process and Numba and cppyy can be freely mixed. This is not possible if LLVM is a shared library and thus has to expose linker symbols.

(Aside, another use case is C++ through the Python interface in Julia. Very silly, yes, but it actually works. :) )

I will remove the hook: I don't like cppyy being loaded just b/c it's installed and someone loads Numba. I was expecting (but did not verify) that Numba would check sys.modules before running hooks. However, even after that, it will still be impossible to mix Numba and cppyy in the conda builds, for the reason mentioned above, at least until that llvmlite on top of Cling work is finished.

[rdemaria]

Could the conda package be compiled like the PyPi build?

[saraedum]

Could the conda package be compiled like the PyPi build?

We'd rather not link llvm statically. It usually causes a lot of trouble down the line.

So, I don't understand how cppyy and numba can depend on incompatible versions of llvm in conda-forge. If both are linking dynamically, then they're using the same library. And if the dependency setup of llvm is correct in conda-forge, then they should refuse to install with an incompatible llvm version.

[wlav]

Patch release 2.4.1 no longer installs the hooks.