build openblas with lapack- and cblas interface fails

[HymiR]

Hi,
I'm trying some experiments with numpy and openblas-0.2.8/0.2.9_rc1.
Since numpy needs cblas and lapack, i think I should build openblas with the appropriate interfaces enabled, if I understood the comments within Makefile.rule (sadly the only build specific "documentation") right.

I set following in Makefile.rule:
TARGET=CORE2
CC=gcc
FC=gfortran
DYNAMIC_ARCH=0
USE_THREAD=0
USE_OPENMP=1 // gcc-4.8.2 with fortran and openmp compiled-in

NO_CBLAS=0
NO_LAPACK=0

I use gentoo linux, gcc-4.8.2[fortran, openmp] on a core2-duo cpu
With the last two entries (NO_*) as described above, building fails with errors like:
linktest: undefined reference to xxxxx

With these entries commented-out build works fine.
Here's my question: do I need the mentioned entires to be activated to get cblas and lapack support?
Do I have to install other libs as dependencies in that case???
What do I need the NO_IFNAME flags actually need for? Why theres no documentation?

Thank you very much in advance, greetings from Germay

[martin-frbg]

Most likely the build system (and/or the #if, #ifdef something... in individual source files) do not check the actual value assigned to NO_CBLAS and NO_LAPACK, but just if this is defined at all. This might be seen as a deficiency of the current code, but on the other hand the comments in Makefile.rule only mention to comment in the "=1" cases when you do not want the respective code (suggestingto leave this alone otherwise). It is my understanding that you would only want to define these if you intended to link your code with an alternative version of BLAS or LAPACK
(supplied by ATLAS or similar libraries) in addition to (what remained of) openBLAS.

[martin-frbg]

BTW using USE_OPENMP=1 in combination with programs that are actually compiled with -fopenmp and use LAPACK calls may work correctly only with the current git head, not with either 0.2.8 and 0.2.9rc1 - see closed bug #329 for details.

[HymiR]

OK, I understand, thank you very much.
I have a last question:
The resulting libopenblas.so, does it contain the functionallity of lapack and cblas?
I built numpy and tried to import it's module and got following error:
ImportError: /home/hymir/testroot/lib/python3.3/site-packages/numpy/linalg/lapack_lite.cpython-33.so: undefined symbol: zgesdd_

openblas was built as described above (the NO_* lines commented-out) with the prefix /myhome/testroot.
For numpy i created a site.cfg with following content:
[openblas]
libraries = openblas
library_dirs = /myhome/testroot/lib
include_dirs = /myhome/testroot/include

I built it using the command:
python setup.py install --prefix=/myhome/testroot

Then i added the corresponding python stuff to PYTHONPATH with:
export PYTHONPATH=${PYTHONPATH}:/myhome/testroot/lib/python3.3/site-packages

Building numpy worked, only the import refuses to work.
BTW, I'm using python 3.3 for that experiment. But it should work according the READMEs.
So, can you help me out here, what did i forget?

Thanx, HymiR

[martin-frbg]

Try running "nm" on your libopenblas - it should show "T zgesdd_" somewhere in the list of functions. If not, try running "make clean" before re-running "make" - perhaps the make mechanism did not pick up the dependency between the NO_... define and the zgesdd source, so the latter was not recompiled after your last change to Makefile.rule ?
If you see zgesdd in the nm output, check the load order of your python modules, and
make sure that openblas actually gets found and loaded.

[HymiR]

Hey, thanks for your hints, i got it now.
I simpy forgot to set PATH and LD_LIBRARY_PATH for /myhome/testroot.
Just one more question: can i use the defines USE_THREAD and USE_OPENMP together set true?
Or is it intendet do activate either the one or the other?

Thank you for your help, you guys are great, keep up that good work! :)

[martin-frbg]

I guess that would work, but it would not make sense performance-wise to have an openblas function that is already called from a thread in some program start creating threads of its own. I believe this is documented somewhere in the FAQ...
Oh, and please close this bug when you are satisfied with the answer, I guess we do not
want to discourage Zhang Xianyi and colleagues from releasing 0.2.9 :-)