New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is rb-gsl too eager to use ATLAS over gslcblas? #3

Closed
dsedivec opened this Issue Apr 13, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@dsedivec

dsedivec commented Apr 13, 2014

I'm on Mac OS X 10.8, GSL 1.16 installed from MacPorts, Ruby 2.1.1. I'm trying to use rb-gsl with the Classifier library, but I'm getting an error. Here's a smaller demonstration of how to reproduce this, without actually calling into Classifier:

# Make a Gemfile that requires rb-gsl.
$ cat > Gemfile <<EOF
> source 'https://rubygems.org'
> gem 'rb-gsl'
> EOF

# Install rb-gsl with Bundler.  I don't *think* use of Bundler is
# particularly important; presumably I could reproduce
# this with just "gem install rb-gsl" too.
$ bundle install --path=vendor/bundle
Fetching gem metadata from https://rubygems.org/...
Resolving dependencies...
Installing narray (0.6.0.8)
Installing rb-gsl (1.16.0)
Using bundler (1.5.3)
Your bundle is complete!
It was installed into ./vendor/bundle

# Here comes the error:
$ bundle exec irb
irb(main):001:0> require 'gsl'
=> true
irb(main):002:0> GSL::Vector.alloc(1).normalize
dyld: lazy symbol binding failed: Symbol not found: _cblas_dnrm2
  Referenced from: /opt/local/lib/libgsl.0.dylib
  Expected in: flat namespace

dyld: Symbol not found: _cblas_dnrm2
  Referenced from: /opt/local/lib/libgsl.0.dylib
  Expected in: flat namespace

Trace/BPT trap: 5

I think the problem might be lines 64-75 in extconf.rb. I say this because, if I neuter this conditional and prevent -lgslcblas from being removed from the list of libraries, rb-gsl works just fine.

Those lines in extconf.rb read to me as, "if you have ATLAS installed, use it instead of gslcblas." I do have ATLAS installed, but my GSL is not using it; my GSL is linked with gslcblas. I would have thought that, if GSL was linked with ATLAS, gsl-config --libs would have said so.

Am I on the right track here? Is this bit of code in extconf.rb problematic, or should I look elsewhere for my problem?

Thank you!

@blackwinter

This comment has been minimized.

Show comment
Hide comment
@blackwinter

blackwinter Apr 14, 2014

Owner

Hi Dale,

to be honest, I, too, can only infer from the code what the original intent might have been. I wouldn't mind hiding that bit behind an option, seeing that it's neither needed on my platforms nor on yours. So we'd wait for someone to come along who actually needs that kind of special treatment.

Out of curiosity, does it work with the original gsl gem?

Cheers
Jens

Owner

blackwinter commented Apr 14, 2014

Hi Dale,

to be honest, I, too, can only infer from the code what the original intent might have been. I wouldn't mind hiding that bit behind an option, seeing that it's neither needed on my platforms nor on yours. So we'd wait for someone to come along who actually needs that kind of special treatment.

Out of curiosity, does it work with the original gsl gem?

Cheers
Jens

@blackwinter

This comment has been minimized.

Show comment
Hide comment
@blackwinter

blackwinter Apr 15, 2014

Owner

Added option --enable-atlas.

Could you check before I'm going to release a new version?

Owner

blackwinter commented Apr 15, 2014

Added option --enable-atlas.

Could you check before I'm going to release a new version?

@dsedivec

This comment has been minimized.

Show comment
Hide comment
@dsedivec

dsedivec Apr 15, 2014

I can confirm that c935212 seems to fix my problem. I can now GSL::Vector.alloc(1).normalize as expected. Thank you! (Unfortunately I could not test with current head, a8ce8f0, as that breaks the build for me. I'll comment on #4 to that effect.)

dsedivec commented Apr 15, 2014

I can confirm that c935212 seems to fix my problem. I can now GSL::Vector.alloc(1).normalize as expected. Thank you! (Unfortunately I could not test with current head, a8ce8f0, as that breaks the build for me. I'll comment on #4 to that effect.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment