Yes - this always bothered me... But I don't think its always possible to automate it.
The likable version [.so] might not exist - only .so.ver might exist? [and it might use blas but not lapack?] Note: one way to avoid this issue is to let spack install python,numpy,petsc,petsc4py Satish ------- $ locate numpy |grep \.so$ |grep python3.11 /usr/lib64/python3.11/site-packages/numpy/core/_multiarray_tests.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/core/_multiarray_umath.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/core/_operand_flag_tests.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/core/_rational_tests.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/core/_simd.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/core/_struct_ufunc_tests.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/core/_umath_tests.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/fft/_pocketfft_internal.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/linalg/_umath_linalg.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/linalg/lapack_lite.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_bounded_integers.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_common.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_generator.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_mt19937.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_pcg64.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_philox.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/_sfc64.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/bit_generator.cpython-311-x86_64-linux-gnu.so /usr/lib64/python3.11/site-packages/numpy/random/mtrand.cpython-311-x86_64-linux-gnu.so $ locate numpy |grep \.so$ |grep python3.11 |xargs ldd |grep = | cut -d = -f 2 | cut -d " " -f 2 | sort | uniq /lib64/libc.so.6 /lib64/libflexiblas.so.3 /lib64/libgcc_s.so.1 /lib64/libgfortran.so.5 /lib64/libm.so.6 /lib64/libquadmath.so.0 On Fri, 21 Oct 2022, Barry Smith wrote: > > When PETSc is built with petsc4py this brings along, in some way, the > BLAS/LAPACK that numpy is using. Yet PETSc is free to bring in its own > BLAS/LAPACK libraries. > > To be completely proper should we be having configure (when used with > petsc4py) determine the BLAS/LAPACK that numpy is using and only using that > for PETSc's BLAS/LAPACK needs? If not, why is ok to have both sets hanging > around? Jose's new https://gitlab.com/petsc/petsc/-/merge_requests/5737 seems > to indicate possible problems with having both. > > Barry