BUG: Undefined math symbols when compiling from source against intel MKL #27111
Labels
Comments
|
@rgommers Apologies for bothering you, but in the past you've helped solve issues at the confluence of numpy and MKL, so perhaps this problem has an obvious solution to you? |
|
The missing symbol is |
|
I can't find any reports about |
Intel Ice Lake, or, from |
|
I have seen this before, let me try and find what the mitigation was |
|
Not that this helps, when I compile against the dynamic library (i.e., |
|
Could you add this to CFLAGS and rebuild? |
|
I had filed this issue a while back and forgot about it :) #26257. This flag should be added into our meson build for icx/icpx compiler. I will submit a PR to do that. |
You mean just CFLAGS='-fveclib=none' on the same line where I'm defining CC and CXX? I am not setting any other CFLAGS anywhere. |
yup |
|
@r-devulap That indeed fixed the issue. Thanks! |
|
I think I need to reopen this issue, unless what I'm seeing is unrelated. With that addition to CFLAGS, numpy built successfully. However, it fails |
The warnings are maybe just Intel compiler enabling fast-math by default and not related to the segfault? (I thought our build process disables it but dunno.) It may be easier to run the test explicitly on its own. (I suspect the above started a new process maybe?) This goes into highway, I wonder if it might make sense to pull from main, but I think the fixes in highway sorting were just for MacOS. |
|
@seberg Thanks for that test code! It fails with the following: The bit about disabling fast-math rings a bell, I will try recompiling numpy with |
|
Not clear whats going on there, I was hoping for segfault from gdb not some python errors anyway... |
The errors I posted from gdb might not have been accurate, so I deleted that comment and am trying to debug just based on the python output. Apologies for that confusion. Basically, on our HPC systems we have "login" nodes where one can run single (or few) threaded applications, and "compute" nodes where one gets up to 80 cores. I realized that the error depended on the number of cores available, not gdb vs non-gdb. |
|
I recompiled numpy with and now |
|
@AgilentGCMS It is still possible that icx compiler doesn't raise all the appropriate floating point exceptions. Could you compile this with icpx and tell me output? Output when using gcc, the last bit is set to 1 which means it raised an invalid FPE: |
|
compile with the |
|
@r-devulap I compiled your code with |
|
The errors look pretty harmless overall. I would guess the math libraries are still using fast-math, so anything that calls out of NumPy into math libs is still sloppy about FPEs. EDIT: Ah, not sure about the |
|
@seberg Any reason why math libraries would still use fast-math even after I've specified |
|
They are dynamically linked and there is only one version of them, no? So either strict, or not. |
|
@seberg I agree, these look specific to ICPX. Most the test failures seem harmless, except I am not sure about these two: Do you know what these failures are? |
So these will disappear if I link with the static library? I'll try. |
I forgot the exact cause but IIRC they are some wrong dtype mappings in f2py (and with that I think just the tests) and probably harmless as well, i.e.the test setup is brittle w.r.t. to new platforms. |
|
static linking or dynamic link shouldn't fix it, I think. The libraries are precompiled and shipped, changing the way you link to them won't affect their behavior. |
|
From the docs, -fp-model=strict should raise all appropriate FP exceptions. |
I can confirm that linking to the static library did not fix/change anything. I get the same failures, including the two you were concerned about. |
I seem to remember this as well. |
|
@AgilentGCMS I am not sure about those exact test failures. However:
|
|
OK, I'm going to close this for now. Thanks for all your help! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the issue:
I have compiled python 3.12.4 from source on a computing cluster, and I am trying to compile numpy. The goal is to install it in the same tree as the locally compiled python binary. We have intel compilers on the cluster, so I am trying to get numpy to use intel MKL libraries. I compiled numpy with
This installed and compiled without complaints. However, when I try to import numpy from within python, I get
An invocation of
lddshows the following libraries linked to the above mentioned shared object file:So what is missing here?
Reproduce the code example:
Error message:
Python and NumPy Versions:
Python 3.12.4
Numpy 2.0.1
Runtime Environment:
Cannot show this because importing numpy fails
Context for the issue:
No response
The text was updated successfully, but these errors were encountered: