Results 1 to 6 of 6

Thread: libarmadillo incorrectly compiled

  1. #1

    Default libarmadillo incorrectly compiled

    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/armadill...rc/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/...apack_lapacke/
    (See the entry under CLAPACK)

    I haven't verified it yet, but I believe libarmadillo should be configured without ARMA_USE_ATLAS

    Thoughts?

  2. #2
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    15,699

    Default Re: libarmadillo incorrectly compiled

    Are you building code?? If so you need the devel package for anything you are linking to.

  3. #3

    Default Re: libarmadillo incorrectly compiled

    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_*)




  4. #4
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,649
    Blog Entries
    15

    Default Re: libarmadillo incorrectly compiled

    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/armadill...rc/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/...apack_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;
    Code:
    [   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/bu...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!


  5. #5

    Default AW: libarmadillo incorrectly compiled

    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

  6. #6

    Default Re: AW: libarmadillo incorrectly compiled

    Quote Originally Posted by Akoellh View Post
    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.
    s/compiled incorrectly/user confusion/
    I found the missing symbols in libsatlas.so (package libatlas3)

    Anyway, thanks for shimming in.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •