Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 757510 - dev-python/numpy: automagically linking against libflame.so
Summary: dev-python/numpy: automagically linking against libflame.so
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: blas-lapack
  Show dependency tree
 
Reported: 2020-11-28 22:33 UTC by Aisha Tammy
Modified: 2020-11-29 12:37 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aisha Tammy 2020-11-28 22:33:56 UTC
Having libflame installed makes numpy link to libflame.so.

How to reproduce
- install https://github.com/flame/libflame into system wide location
- emerge numpy
- check out shared libraries installed by numpy and see which of them are linked to libflame.so

equery f dev-python/numpy | grep '\.so' | while read ff; do if ldd $ff | grep -q flame; then echo $ff; ldd $ff; fi; done

Output - 

/usr/lib/python3.7/site-packages/numpy/linalg/_umath_linalg.cpython-37m-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffde07c7000)
        libflame.so.2 => /usr/lib64/libflame.so.2 (0x00007f94c6ccd000)
        libcblas.so.3 => /usr/lib64/libcblas.so.3 (0x00007f94c6cb0000)
        libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007f94c6c5f000)
        libpython3.7m.so.1.0 => /usr/lib64/libpython3.7m.so.1.0 (0x00007f94c6958000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f94c679e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f94c6667000)
        libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgomp.so.1 (0x00007f94c6625000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f94c6605000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f94c7d66000)
        libgfortran.so.5 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so.5 (0x00007f94c6343000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f94c633e000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f94c6339000)
        libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libquadmath.so.0 (0x00007f94c62ed000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgcc_s.so.1 (0x00007f94c62d3000)
/usr/lib/python3.7/site-packages/numpy/linalg/lapack_lite.cpython-37m-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffff8b3e000)
        libflame.so.2 => /usr/lib64/libflame.so.2 (0x00007f38c1d1c000)
        libcblas.so.3 => /usr/lib64/libcblas.so.3 (0x00007f38c1cff000)
        libpython3.7m.so.1.0 => /usr/lib64/libpython3.7m.so.1.0 (0x00007f38c19f8000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f38c183e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f38c1707000)
        libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgomp.so.1 (0x00007f38c16c7000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f38c16a5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f38c2d93000)
        libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007f38c1654000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f38c164f000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f38c164a000)
        libgfortran.so.5 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so.5 (0x00007f38c1388000)
        libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libquadmath.so.0 (0x00007f38c133c000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgcc_s.so.1 (0x00007f38c1322000)


Expected result - only link to libblas.so,libcblas.so,liblapack.so


Reasoning - possibly numpy mechanism for selection of libraries puts libflame at a higher priority than standard lapack.

Possible solution - somehow (?) make the numpy build system not see libflame? I am unsure what the numpy build system is doing and how it works.