[Kst] Re: The crash when using a gsl-based fit plugin: possible solution

Peter Kümmel syntheticpp at gmx.net
Sat Mar 19 13:34:37 CET 2011

On 19.03.2011 13:13, Nicolas Brisset wrote:
>>> It seems that making the gsl flags "-Wl,--no-as-needed -lgsl
>> -lgslcblas -lm" and making sure they are at the end of the list should
>> fix the issue.
>>> Peter, could you try to add that to cmake so that I can check
>> whether it works? Having all fit plugins crash is really bad. We
>> should try to fix it, especially if there is a known solution. I'm
>> actually surprised that it does not crash on other Linux systems as
>> this way of linking seems to be the default for gsl.
>> As I understand it, gsl loads a blas lib at runtime. Have you
>> installed one of them on your sytem?
> Yes, it is in fact part of the gsl package. It's just that somehow it is not correctly linked.
> nicolas at linux-cwbq:~>  rpm -ql gsl
> /usr/bin/gsl-histogram
> /usr/bin/gsl-randist
> /usr/lib/libgsl.so.0
> /usr/lib/libgsl.so.0.15.0
> /usr/lib/libgslcblas.so.0
> /usr/lib/libgslcblas.so.0.0.0
> Is it difficult to try the above mentioned switch? I guess changing the gsl flags when gsl is found should do the trick...

It's not difficult to add such options but I don't think it will fix it, or have you tried?

The bug report you mentioned is about build time because resolving all files was required by --as-needed.

But you have a runtime error.

Does 'ldd' list libgslcblas.so when you call it on a gsl plugin?

Here on Ubuntu we link against cblas:
-- Found Gsl:
--      includes : /usr/include/gsl;/usr/include/gsl/..
--      libraries: /usr/lib/libgsl.so;/usr/lib/libgslcblas.so;/usr/lib/libm.so

Could you check the output of your cmake.


More information about the Kst mailing list