==11658== Memcheck, a memory error detector
==11658== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11658== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==11658== Command: ./matrix/matrix-lib-test
==11658==
LOG (UnitTestTridiagonalize():matrix-lib-test.cc:1530) S trace 432, T trace 432
./matrix/matrix-lib-test: symbol lookup error: ./matrix/matrix-lib-test: undefined symbol: clapack_sgetrf
==11658==
==11658== HEAP SUMMARY:
==11658== in use at exit: 9,001 bytes in 24 blocks
==11658== total heap usage: 50 allocs, 26 frees, 22,706 bytes allocated
==11658==
==11658== LEAK SUMMARY:
==11658== definitely lost: 0 bytes in 0 blocks
==11658== indirectly lost: 0 bytes in 0 blocks
==11658== possibly lost: 0 bytes in 0 blocks
==11658== still reachable: 9,001 bytes in 24 blocks
==11658== suppressed: 0 bytes in 0 blocks
==11658== Rerun with --leak-check=full to see details of leaked memory
==11658==
==11658== For counts of detected and suppressed errors, rerun with: -v
==11658== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
What is wrong? Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is caused by atlas libraries... While the compiler was able to
see and use them, the runtime resolver cannot find those.
Go to src directory and issue
ldd ./matrix/matrix-lib-test
You will probably see that some libraries are marked as not found. Fix the
runtime environment (either /etc/ld.conf or LD_LIBRARY_PATH environment
variable) so that these libraries will be usable.
y.
==11658== Memcheck, a memory error detector
==11658== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11658== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for
copyright info
==11658== Command: ./matrix/matrix-lib-test
==11658==
LOG (UnitTestTridiagonalize():matrix-lib-test.cc:1530) S trace 432, T
trace 432
./matrix/matrix-lib-test: symbol lookup error: ./matrix/matrix-lib-test:
undefined symbol: clapack_sgetrf
==11658==
==11658== HEAP SUMMARY:
==11658== in use at exit: 9,001 bytes in 24 blocks
==11658== total heap usage: 50 allocs, 26 frees, 22,706 bytes allocated
==11658==
==11658== LEAK SUMMARY:
==11658== definitely lost: 0 bytes in 0 blocks
==11658== indirectly lost: 0 bytes in 0 blocks
==11658== possibly lost: 0 bytes in 0 blocks
==11658== still reachable: 9,001 bytes in 24 blocks
==11658== suppressed: 0 bytes in 0 blocks
==11658== Rerun with --leak-check=full to see details of leaked memory
==11658==
==11658== For counts of detected and suppressed errors, rerun with: -v
==11658== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
clapack_sgetrf is supposed to be provided by the ATLAS library... it
is a part of the LAPACK interface, note core BLAS, but it's part of
that subset which ATLAS provides.
However, looking at the configure script, and specifically the
function linux_configure_debian_ubuntu, it looks like the library
ATLAS provides for its subset of lapack is called something like
/usr/lib{,64}/atlas-base/liblapack_atlas.so.3gf. Probably it should
have _atlas in the name at the very least. It could be that you
installed a "native" LAPACK on your system, yet the system is trying
to use Atlas.
If you run "configure" and show the output, it would be helpful.
./configure
Configuring ...
Checking OpenFST library in /opt/software/kaldi/tools/openfst ...
Checking OpenFst library was patched.
Backing up kaldi.mk to kaldi.mk.bak
Doing OS specific configurations ...
On Linux: Checking for linear algebra header files ...
Using ATLAS as the linear algebra library.
Atlas found in /usr/lib
... no libatlas.so in /usr/lib/atlas
... no libatlas.so in /usr/lib/atlas-sse2
... no libatlas.so in /usr/lib/atlas-sse3
... no libatlas.so in /usr/lib64
... no libatlas.so in /usr/lib64/atlas
... no libatlas.so in /usr/lib64/atlas-sse2
... no libatlas.so in /usr/lib64/atlas-sse3
... no libatlas.so in /usr/local/lib
... no libatlas.so in /usr/local/lib/atlas
... no libatlas.so in /usr/local/lib/atlas-sse2
... no libatlas.so in /usr/local/lib/atlas-sse3
... no libatlas.so in /usr/local/lib64
... no libatlas.so in /usr/local/lib64/atlas
... no libatlas.so in /usr/local/lib64/atlas-sse2
... no libatlas.so in /usr/local/lib64/atlas-sse3
... no libatlas.so in /opt/software/kaldi/src/../tools/ATLAS/build/install/lib/
... no libatlas.so in /opt/software/kaldi/tools/ATLAS/lib
Looking for ATLAS libs in /usr/lib
Using library -L/usr/lib -llapack as ATLAS's CLAPACK library.
CUDA will not be used! If you have already installed cuda drivers and cuda toolkit, try using --cudatk-dir=... option. Note: this is only relevant for neural net experiments
Static=[false] Speex library not found: You can still build Kaldi without Speex.
Successfully configured for Linux [dynamic libraries] with ATLASLIBS =-L/usr/lib -llapack -lcblas -latlas -lf77blas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made an install on a second machine, where it worked and compared the installed packages incl. version numbers. On the machine where the test failed was liblapack-dev missing. After install and a make clean and a new make the test succeeded.
Thank you for your time and help.
Last edit: sedgrepawk 2014-11-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, but that still doesn't really make me happy as it's supposed to
work out of the box. liblapack-dev shouldn't be relevant at all,
everything you need should be in the ATLAS package (we don't use
liblapack per se, only the ATLAS version).
Could you do
nm --dynamic /usr/lib/liblapack.so.3 | grep cgetrf
on the machine where it failed, and show me what it says?
The configure script seems to check that it contains ATL_cgetrf, and
it should also (since it is the ATLAS library) contain the wrapping
symbol clapack_cgetrf which is what is immediately required.
I made an install on a second machine, where it worked and compared the
installed packages incl. version numbers. On the machine where the test
failed was liblapack-dev missing. After install and a make clean and a new
make the test succeeded.
./matrix/matrix-lib-test: symbol lookup error: ./matrix/matrix-lib-test:
undefined symbol: clapack_sgetrf
OK, that's confusing because in the linux_configure_dynamic function
in the configure script, it checks that ATL_cgetrf is in that file.
Please verify that /usr/lib/liblapack.so points to liblapack.so.3.
And then run the configure script again. At line 569 of "configure",
it checks that ATL_cgetf is defined there-- please try to figure out
why it said it was there when it was not there.
Dan
Hello,
I tried to "make test" a successfully built Kaldi on Ubuntu 14.04 with gcc/g++ 4.9.2 and got following error:
make[1]: Entering directory `/opt/software/kaldi/src/matrix'
Running matrix-lib-test ...... FAIL matrix-lib-test
valgrind says:
==11658== Memcheck, a memory error detector
==11658== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11658== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==11658== Command: ./matrix/matrix-lib-test
==11658==
LOG (UnitTestTridiagonalize():matrix-lib-test.cc:1530) S trace 432, T trace 432
./matrix/matrix-lib-test: symbol lookup error: ./matrix/matrix-lib-test: undefined symbol: clapack_sgetrf
==11658==
==11658== HEAP SUMMARY:
==11658== in use at exit: 9,001 bytes in 24 blocks
==11658== total heap usage: 50 allocs, 26 frees, 22,706 bytes allocated
==11658==
==11658== LEAK SUMMARY:
==11658== definitely lost: 0 bytes in 0 blocks
==11658== indirectly lost: 0 bytes in 0 blocks
==11658== possibly lost: 0 bytes in 0 blocks
==11658== still reachable: 9,001 bytes in 24 blocks
==11658== suppressed: 0 bytes in 0 blocks
==11658== Rerun with --leak-check=full to see details of leaked memory
==11658==
==11658== For counts of detected and suppressed errors, rerun with: -v
==11658== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
What is wrong? Thanks in advance.
The problem is caused by atlas libraries... While the compiler was able to
see and use them, the runtime resolver cannot find those.
Go to src directory and issue
ldd ./matrix/matrix-lib-test
You will probably see that some libraries are marked as not found. Fix the
runtime environment (either /etc/ld.conf or LD_LIBRARY_PATH environment
variable) so that these libraries will be usable.
y.
On Wed, Nov 26, 2014 at 11:40 AM, sedgrepawk sedgrepawk@users.sf.net
wrote:
Thanks for the fast reply.
ldd ./matrix/matrix-lib-test
linux-vdso.so.1 => (0x00007fff121fe000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007fd7dccc7000)
libf77blas.so.3 => /usr/lib/libf77blas.so.3 (0x00007fd7dcaa7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd7dc888000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd7dc57c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd7dc276000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd7dc05e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7dbc98000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fd7db6cc000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fd7db3b2000)
libcblas.so.3 => /usr/lib/libcblas.so.3 (0x00007fd7db191000)
libatlas.so.3 => /usr/lib/libatlas.so.3 (0x00007fd7dabfe000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd7dd47e000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fd7da9bf000)
Seems good to me. Can you see the problem?
Did you try run the matrix-lib-test binary?
If that works, then possibly some interaction with the valgrind is the
cause of the troubles.
y.
On Wed, Nov 26, 2014 at 1:11 PM, sedgrepawk sedgrepawk@users.sf.net wrote:
./matrix/matrix-lib-test
LOG (UnitTestTridiagonalize():matrix-lib-test.cc:1530) S trace 432, T trace 432
./matrix/matrix-lib-test: symbol lookup error: ./matrix/matrix-lib-test: undefined symbol: clapack_sgetrf
That is what I get if I run the binary. Within "make test" it simply fails.
clapack_sgetrf is supposed to be provided by the ATLAS library... it
is a part of the LAPACK interface, note core BLAS, but it's part of
that subset which ATLAS provides.
However, looking at the configure script, and specifically the
function linux_configure_debian_ubuntu, it looks like the library
ATLAS provides for its subset of lapack is called something like
/usr/lib{,64}/atlas-base/liblapack_atlas.so.3gf. Probably it should
have _atlas in the name at the very least. It could be that you
installed a "native" LAPACK on your system, yet the system is trying
to use Atlas.
If you run "configure" and show the output, it would be helpful.
Dan
On Wed, Nov 26, 2014 at 7:25 AM, sedgrepawk sedgrepawk@users.sf.net wrote:
./configure
Configuring ...
Checking OpenFST library in /opt/software/kaldi/tools/openfst ...
Checking OpenFst library was patched.
Backing up kaldi.mk to kaldi.mk.bak
Doing OS specific configurations ...
On Linux: Checking for linear algebra header files ...
Using ATLAS as the linear algebra library.
Atlas found in /usr/lib
... no libatlas.so in /usr/lib/atlas
... no libatlas.so in /usr/lib/atlas-sse2
... no libatlas.so in /usr/lib/atlas-sse3
... no libatlas.so in /usr/lib64
... no libatlas.so in /usr/lib64/atlas
... no libatlas.so in /usr/lib64/atlas-sse2
... no libatlas.so in /usr/lib64/atlas-sse3
... no libatlas.so in /usr/local/lib
... no libatlas.so in /usr/local/lib/atlas
... no libatlas.so in /usr/local/lib/atlas-sse2
... no libatlas.so in /usr/local/lib/atlas-sse3
... no libatlas.so in /usr/local/lib64
... no libatlas.so in /usr/local/lib64/atlas
... no libatlas.so in /usr/local/lib64/atlas-sse2
... no libatlas.so in /usr/local/lib64/atlas-sse3
... no libatlas.so in /opt/software/kaldi/src/../tools/ATLAS/build/install/lib/
... no libatlas.so in /opt/software/kaldi/tools/ATLAS/lib
Looking for ATLAS libs in /usr/lib
Using library -L/usr/lib -llapack as ATLAS's CLAPACK library.
CUDA will not be used! If you have already installed cuda drivers and cuda toolkit, try using --cudatk-dir=... option. Note: this is only relevant for neural net experiments
Static=[false] Speex library not found: You can still build Kaldi without Speex.
Successfully configured for Linux [dynamic libraries] with ATLASLIBS =-L/usr/lib -llapack -lcblas -latlas -lf77blas
Hello. Good news.
I made an install on a second machine, where it worked and compared the installed packages incl. version numbers. On the machine where the test failed was liblapack-dev missing. After install and a make clean and a new make the test succeeded.
Thank you for your time and help.
Last edit: sedgrepawk 2014-11-27
OK, but that still doesn't really make me happy as it's supposed to
work out of the box. liblapack-dev shouldn't be relevant at all,
everything you need should be in the ATLAS package (we don't use
liblapack per se, only the ATLAS version).
Could you do
nm --dynamic /usr/lib/liblapack.so.3 | grep cgetrf
on the machine where it failed, and show me what it says?
The configure script seems to check that it contains ATL_cgetrf, and
it should also (since it is the ATLAS library) contain the wrapping
symbol clapack_cgetrf which is what is immediately required.
Dan
On Thu, Nov 27, 2014 at 4:42 AM, sedgrepawk sedgrepawk@users.sf.net wrote:
OK, that's confusing because in the linux_configure_dynamic function
in the configure script, it checks that ATL_cgetrf is in that file.
Please verify that /usr/lib/liblapack.so points to liblapack.so.3.
And then run the configure script again. At line 569 of "configure",
it checks that ATL_cgetf is defined there-- please try to figure out
why it said it was there when it was not there.
Dan
On Fri, Nov 28, 2014 at 8:03 AM, sedgrepawk sedgrepawk@users.sf.net wrote:
in /usr/lib:
liblapack.so -> /etc/alternatives/liblapack.so
in /etc/alternatives:
liblapack.so -> /usr/lib/lapack/liblapack.so
in /usr/lib/lapack:
liblapack.so -> liblapack.so.3
liblapack.so.3.0
Check. I did not modify anything within these folders.
Configure successful again.
Using library -L/usr/lib -llapack_atlas as ATLAS's CLAPACK library.
I have actually no idea what went wrong, and why it is working now.