[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] GSL runtime error/symbol lookup error

From: Ernst-Jan Buis
Subject: Re: [Help-gsl] GSL runtime error/symbol lookup error
Date: Sat, 5 Jan 2013 17:43:15 +0100

Dear Rhys,

The LD_LIBRARY_PATH settings were correct and both libgls and libglscblas
were in the same directory.
I find it suprising to find that when I check my executable with for its
shared libraries with ldd, I find that the executable
depends on libgsl, but not on libgslcblas (although I included the
libgslcblas in my link-line through: gsl-config --cflags --libs)
The output of ldd -r testgsl gives: =>  (0x00007fff9deae000) => /usr/lib/ (0x00007ffbcecfd000) => /usr/lib/x86_64-linux-gnu/
(0x00007ffbce9cd000) => /lib/x86_64-linux-gnu/ (0x00007ffbce748000) => /lib/x86_64-linux-gnu/
(0x00007ffbce532000) => /lib/x86_64-linux-gnu/ (0x00007ffbce18f000)
    /lib64/ (0x00007ffbcf13b000)
undefined symbol: cblas_ctrmv    (/usr/lib/
undefined symbol: cblas_zswap    (/usr/lib/
undefined symbol: cblas_zsymm    (/usr/lib/

This means that my executable (called Ā“testgslĀ“) is not linked against
libgslcblas. I guess that libgsl,so should be linked against

On Sat, Jan 5, 2013 at 3:08 PM, Rhys Ulerich <address@hidden> wrote:

> > Yes, I'm linking with the proper CBLAS lib
> I apologize... I had not read your message closely enough to realize it
> was a runtime issue.
> Are both dynamic libraries in a directory searched at runtime? E.g. if you
> add the directory containing the CBLAS .so to your LD_LIBRARY_PATH does ldd
> report everything is okay?
> - Rhys

reply via email to

[Prev in Thread] Current Thread [Next in Thread]