I just upraded to Ruby 1.8.3 (from sources) on my Redhat Linux box.
When I attempt to do anything that starts a new thread, I receive the
message “ThreadError: uninitialized thread - check
`Thread#initialize’”. Below is a transcript from a one-line session in
IRB that demonstrates the problem. Any ideas? (Please let me know if
there is other information that would be helpful in diagnosing this.)
irb(main):001:0> Thread.new { puts ‘hi’ }
ThreadError: uninitialized thread - check Thread#initialize' from (irb):1:innew’
from (irb):1
irb(main):002:0>
Thank you!
On Tue, 22 Nov 2005, Eric K wrote:
from (irb):1
irb(main):002:0>
can you show us how you compiled ruby?
-a
Eric K wrote:
from (irb):1:in `new'
from (irb):1
irb(main):002:0>
Works for me:
irb(main):001:0> Thread.new { puts ‘hi’ }
hi=> #<Thread:0x101d74b0 run>
Ruby 1.8.3 on cygwin.
Kind regards
robert
On Monday 21 November 2005 03:32 pm, Eric K wrote:
I just upraded to Ruby 1.8.3 (from sources) on my Redhat Linux box.
When I attempt to do anything that starts a new thread, I receive the
message “ThreadError: uninitialized thread - check
`Thread#initialize’”. Below is a transcript from a one-line session in
IRB that demonstrates the problem. Any ideas? (Please let me know if
there is other information that would be helpful in diagnosing this.)
The ruby executable links against libruby18.so. If you downloaded and
installed ruby into /usr/local or something like that, perhaps at
runtime
your new ruby binary is still linking against the older ruby library. A
quick use of ‘ldd’ will help determine that.
Caleb
Here’s the output from ‘ldd’ of /usr/local/bin/ruby:
libdl.so.2 => /lib/libdl.so.2 (0x200000000005c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x2000000000078000)
libm.so.6.1 => /lib/tls/libm.so.6.1 (0x20000000000c0000)
libc.so.6.1 => /lib/tls/libc.so.6.1 (0x2000000000154000)
/lib/ld-linux-ia64.so.2 => /lib/ld-linux-ia64.so.2
(0x2000000000000000)
Looks okay to me. My binary also links against /usr/lib/libruby18.so,
but
it looks like yours is statically built in.
Does your test program fail in the same way if you don’t use irb, but
instead just run it through ruby? Have you tried running any of the
test
programs that came bundled in the ruby .tar.gz (in the test
subdirectory,
I believe) ?
Thanks for the replies.
Ara >> can you show us how you compiled ruby?
I installed Ruby 1.8.3 from source using (I believe) the standard
“compile/make/make install” cycle. (It’s been a week or so, so the
memory’s a bit weak). Might there have been special switches I’d have
needed for Redhat Enterprise Server 3?
Caleb >> perhaps at runtime your new ruby binary is still linking
against
Caleb >> the older ruby library. A quick use of ‘ldd’ will help
determine that.
Here’s the output from ‘ldd’ of /usr/local/bin/ruby:
libdl.so.2 => /lib/libdl.so.2 (0x200000000005c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x2000000000078000)
libm.so.6.1 => /lib/tls/libm.so.6.1 (0x20000000000c0000)
libc.so.6.1 => /lib/tls/libc.so.6.1 (0x2000000000154000)
/lib/ld-linux-ia64.so.2 => /lib/ld-linux-ia64.so.2
(0x2000000000000000)
Unfortunately I’m not sure what to make of it. Is there a way to tell
if the ‘/lib/ld-linux-ia64.so.2’ referenced is for 1.8.2, 1.8.3, or
1.6?
Thanks again!
Thank you for your help on this. I believe I have resolved the issue.
On my particular Linux (Redhat Enterprise 3), I have to modify the
CFLAGS setting in the Makefile after running ./configure (but before
running make, make install).
After changing the CFLAGS line from:
CFLAGS = -g -O2
to:
CFLAGS = -g -O0
I am able to build Ruby that handles Threads properly. I think the
reason some things were working (and some not) was that I had some .o
files hanging around from a previous build (one done without the CFLAGS
change).
Thanks again for the help, everyone!