This MR attempts to resolve widely-seen issues using the LAL SWIG bindings for a version of LAL linked against FFTW in an environment where the
libblas implementation is linked against MKL.
In this scenario you regularly see things like this:
>>> import numpy
>>> import lal
>>> lal.CreateForwardREAL8FFTPlan(512, 1)
XLAL Error - XLALCreateREAL8FFTPlan (/home/conda/feedstock_root/build_artifacts/lal-split_1698222321355/work/lib/fft/RealFFT_source.c:120): Generic failure
XLAL Error - XLALCreateForwardREAL8FFTPlan (/home/conda/feedstock_root/build_artifacts/lal-split_1698222321355/work/lib/fft/RealFFT_source.c:136): Internal function call failed: Generic failure
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Internal function call failed: Generic failure
The issue is that, when
numpy is imported first, the FFTW-related symbols from MKL are loaded into the global namespace, so when
liblal.so is loaded it uses the MKL symbols instead of the FFTW symbols, and things fall over.
The solution is to somehow force
liblal.so to use the symbols from the library against which it is linked, and the attached patch is the most generic and least intrusive way I have come up with so far.
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions
This change adds new classes/functions/structs/types to a public C header file or Python module
This change modifies an existing class/function/struct/type definition in a public C header file or Python module
This change removes an existing class/function/struct/type from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please provide a justification why this change is necessary and why it needs to be done in a backwards incompatible way.
Please provide details on any reviews related to this change and and the associated reviewers.