I believe libarmadillo5-5.600.2-3.1.x86_64 as packaged in Leap 42.1 has been configured incorrectly.
Trying to link against libarmadillo fails due to a bunch of undefined references like clapack_cgetrf, cblas_sgemv,…
Looking at the code here, https://github.com/lsolanka/armadillo/blob/master/src/wrapper.cpp these should only be defined if the library was compiled with support for the ATLAS library.
#if defined(ARMA_USE_ATLAS)
…
#endif
If you do ldd /usr/lib64/libarmadillo.so you get a list of libraries, including libtatlas, libblas, liblapack, libfortran…
But none of them contain the missing references.
On a Mint system, the program links fine. And doing a **readelf -Ws /usr/lib/libarmadillo.so **on the Mint version show that that library doesn’t contain these symbols.
Doing ldd on the Mint system shows exactly the same entries as on Leap 42.1 EXCEPT that it doesn’t list libtatlas.
Reading this document, it seems that ATLAS isn’t really a standard library, and it is incomplete.
http://nicolas.limare.net/pro/notes/2014/10/31_cblas_clapack_lapacke/
(See the entry under CLAPACK)
I haven’t verified it yet, but I believe libarmadillo should be configured without ARMA_USE_ATLAS
Thoughts?
Are you building code?? If so you need the devel package for anything you are linking to.
I do have the dev libraries.
This is a more fundamental problem: With code that doesn’t call clapack_cgetrf, or cblas_sgemv, linking fails because it can’t resolve them (and a bunch more, essentially everything that is within that #if defined)
I see these symbols listed as UND in libarmadillo.so but I can’t find a library that resolves them in the list of dependencies.
Some of the cblas_* can be found in libcblas.so (which is not listed as a dependency) but I can’t find clapack_* in liblapacke3.so or liblapacke.so (they define LAPACKE_, not lapacke_)
On Tue 04 Apr 2017 05:06:02 AM CDT, mjskier wrote:
I believe libarmadillo5-5.600.2-3.1.x86_64 as packaged in Leap 42.1 has
been configured incorrectly.
Trying to link against libarmadillo fails due to a bunch of undefined
references like clapack_cgetrf, cblas_sgemv,…
Looking at the code here,
https://github.com/lsolanka/armadillo/blob/master/src/wrapper.cpp these
should only be defined if the library was compiled with support for the
ATLAS library.
#if defined(ARMA_USE_ATLAS)
…
#endif
If you do ldd /usr/lib64/libarmadillo.so you get a list of libraries,
including libtatlas, libblas, liblapack, libfortran…
But none of them contain the missing references.
On a Mint system, the program links fine. And doing a *readelf -Ws
/usr/lib/libarmadillo.so *on the Mint version show that that library
doesn’t contain these symbols.
Doing ldd on the Mint system shows exactly the same entries as on Leap
42.1 EXCEPT that it doesn’t list libtatlas.
Reading this document, it seems that ATLAS isn’t really a standard
library, and it is incomplete.
http://nicolas.limare.net/pro/notes/2014/10/31_cblas_clapack_lapacke/
(See the entry under CLAPACK)
I haven’t verified it yet, but I believe libarmadillo should be
configured without ARMA_USE_ATLAS
Thoughts?
Hi
You need to raise a bug report if you think it’s incorrect…
http://en.opensuse.org/openSUSE:Submitting_bug_reports
Looking at the build log, I see ATLAS_FOUND=NO;
37s] -- Found BLAS: /usr/lib64/libblas.so
37s] -- Found LAPACK: /usr/lib64/liblapack.so
37s] -- MKL_FOUND = NO
37s] -- ACMLMP_FOUND = NO
37s] -- ACML_FOUND = NO
37s] -- OpenBLAS_FOUND = NO
37s] -- ATLAS_FOUND = NO
37s] -- BLAS_FOUND = YES
37s] -- LAPACK_FOUND = YES
Ref: https://build.opensuse.org/public/build/devel:libraries:c_c++/openSUSE_Leap_42.2/x86_64/armadillo/_log
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.38-50-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
I do not see why a bug report would be justified, at best this would be a feature request.
This lib is not “compiled incorrectly”, otherwise it would not build.
However, it is built without some optional (sic!) feature and as a consequence building some other software requiring that library with that optional feature does not build.
So raising a feature request would be a much better idea as there is no real bug here, if you would call every lib not having all otional switches enabled a bug, bugzilla would explode.
In addition, I would assume a maintainer getting a feature request would much more likely accept a request for adding a feature when not throwing the word “bug” at her/him.
AK
s/compiled incorrectly/user confusion/
I found the missing symbols in libsatlas.so (package libatlas3)
Anyway, thanks for shimming in.