Hmm, I tried the LD_LIBRARY_PATH thing and still no luck.  But, gga gave the
suggestion that perhaps it is a bad idea (or even now crashing) for the other
reason that Ruby has its own threads that are probably grossly incompatible
with OpenMP threading.  So, I instead rewrote the entire Ruby binding and also
made a new standalone application called uncd: the Universal NCD connectort.
It uses stdin and stdout with a handmade protocol to communicate with
a server process to allow easy language binding in Ruby and Erlang and
eventually Perl, Java, Python etc.  Here is the source code if you are
interested I think it is a major improvement over the old code and
will be doing this for future bindings too I think:

http://hg.cilibrar.com/complearn-uncd/

I learned this approach from Erlang books.  I think I like the idea of
coarse-grained libraries providing functionality via separate
process-space as we move into ubiquitous multicore land.

Thanks for taking the time to try some answers I always have more to
learn about the LD_* variables and dynamic linking.

best regards,

-r.

On 10/6/07, -a <ara.t.howard / gmail.com> wrote:
>
>
> On Oct 4, 5:22 am, "Rudi Cilibrasi" <cilib... / gmail.com> wrote:
> > Hi Ara,
> >
> > Good to hear from you and I am glad to hear you are still thinking about dynamic
> > linking issues.  Unfortunately I tried your suggestion and so far I
> > cannot detect any measurable difference in behavior.  Same error
> > messages in both cases, with and without the #have_library(gomp...)
> > line.
> >
> > Yes, it has taken years but I have rewritten complearn to use gobject
> > and OpenMP and I must say the results are exciting.  Recently,
> > somebody sent in a patch to improve the complearn tree search from
> > O(n^5) to O(n^3) and this really made my week last week, speeding up
> > tree search by thousands of times.  I am very excited to start
> > applying the new technology but this whole ruby extension thing openmp
> > problem has rained on my parade!  nice to hear from you again, -r.
>
>
> try setting LD_LIBRARY_PATH to the location of libgimp (directory
> containing lib) and see if that helps
>
> for example
>
>   export LD_LIBRARY_PATH=/usr/local/lib/
>   ruby a.rb
>
> and see if you still get the error.  if dlopen fails then there is
> some other issue.  make sure the lib is actually there - if it this
> works then massaging LD_RUN_PATH *should* work.
>
> regards.
>
>
>


-- 
"We can try to do it by breaking free of the mental prison of
separation and exclusion and see the world in its interconnectedness
and non-separability, allowing new alternatives to emerge." -- after
Vandana Shiva