Problem with ruby1.8 and OpenMP in Ruby extension: shared object cannot be dlopen()'ed

Hi everybody,

I am the main developer of CompLearn, an open-source machine learning
for scientific researchers. I have written a Ruby binding for
called complearn-ruby. It has worked fine in the past. But it has a
ever since I converted the base library (libcomplearn) to use OpenMP
multicore processor support. If I just try to use the simplest
approach that
has worked in the past in my extconf.rb, I get the following problem
when I
try to require the C-extension Ruby binding and use the
multicore part of the system:

ruby: symbol lookup error: /usr/lib/ undefined
symbol: GOMP_parallel_start

To try to fix this error,

I adjusted the extconf.rb to include this line:

have_library(‘gomp’, ‘main’)

And rebuilding works but running a simple test program (just trying to
complearn) fails in a different way than before:

/home/cilibrar/rlc/projects/complearn/complearn-ruby/ext/complearn/ shared object cannot be dlopen()ed - /
home/cilibrar/rlc/projects/complearn/complearn-ruby/ext/complearn/ (LoadError)
from /home/cilibrar/rlc/projects/complearn/complearn-ruby/lib/
from tests/t2.rb:1:in `require’
from tests/t2.rb:1

I don’t know what else to try and wonder if anybody else can offer a

I have tried for a long time experimenting with CFLAGS, CPPFLAGS,
and -fopenmp among other settings but I still cannot seem to figure
a solution. I have put the source code for this problem up at

I would appreciate greatly any help anybody can offer in this
problem. Thank
you for your attention,


/home/cilibrar/rlc/projects/complearn/complearn-ruby/ext/complearn/ shared object cannot be dlopen()ed - /

That probably means you have some undefined symbol most likely due to
a missing library during link time.

That being said, even if you manage to load and compile the stuff,
wrapping an OpenMP library is probably asking for trouble as ruby is
a single threaded application that relies on knowing how and where the
stack is. OpenMP will generate new threads behind your back, each one
with its own stack. Any call from those threads back to ruby will
probably lead to random crashes or memory issues.

Thanks for this excellent suggestion. You inspired me to write a much
superior stdin/stdout style connector instead using pipes that is far
more flexible in many ways:

Best regards,