I’m a Mac newbie, so I’m struggling a bit here, but there’s a definite
problem loading shared extensions under Mac OSX 10.2.2.
If I run the following
ruby -rsocket -e1
it blows up doing the rb_define_class in Init_socket(). The problem is
that sym_tbl (in parse.y) is apparently 0x0000000. However, tracing
the value in sym_tbl just before the call to Init_socket shows it to
be perfectly valid.
It seems that code in the dynamically loaded object (socket.bundle in
this case) is picking up a different set up global statics, so that
calls from within the shared object are failing.
I know next to nothing about Darwin, but I read that the handling of
shared objects changed between 10.0 and 10.2, with 10.2 supporting two
levels of namespace. I’m wondering if this has anything to do with the
change.
As corroboration, if I link socket.c in to the interpreter statically,
the problem goes away (although I do get warnings about duplicate
symbols when it runs).
I’m happy to do experiments for folks, and I’m continuing some
background research, but if anyone actually knows the Mac it would
probably go a lot quicker if they could have a look at this
I have not tried other version which isn’t installed on my mac yet.
regards,
···
At Thu, 12 Dec 2002 09:31:39 +0900, Dave Thomas wrote:
I’m a Mac newbie, so I’m struggling a bit here, but there’s a definite
problem loading shared extensions under Mac OSX 10.2.2.
If I run the following
ruby -rsocket -e1
it blows up doing the rb_define_class in Init_socket(). The problem is
that sym_tbl (in parse.y) is apparently 0x0000000. However, tracing
the value in sym_tbl just before the call to Init_socket shows it to
be perfectly valid.
On Thursday, 12 December 2002 at 9:31:39 +0900, Dave Thomas wrote:
I’m a Mac newbie, so I’m struggling a bit here, but there’s a definite
problem loading shared extensions under Mac OSX 10.2.2.
I know next to nothing about Darwin, but I read that the handling of
shared objects changed between 10.0 and 10.2, with 10.2 supporting two
levels of namespace. I’m wondering if this has anything to do with the
change.
As corroboration, if I link socket.c in to the interpreter statically,
the problem goes away (although I do get warnings about duplicate
symbols when it runs).
I’m happy to do experiments for folks, and I’m continuing some
background research, but if anyone actually knows the Mac it would
probably go a lot quicker if they could have a look at this
–
Jim Freeze
Never commit yourself! Let someone else commit you.
Agreed, my 1…7 worked too, but… there were problems with the
networking code. For example, by trivial HTTP timeserver application
worked fine if I telneted in to it, if I invoked it from another Ruby
script, but it locked up when invoked from Explorer. I suspected an IPV6
bug, which is why I embarked on the attempt to upgrade to 1.7.
Cheers
Dave
···
On Wed, 2002-12-11 at 20:47, FUJIMOTO Hisakuni wrote:
At Thu, 12 Dec 2002 09:31:39 +0900, > Dave Thomas wrote:
I’m a Mac newbie, so I’m struggling a bit here, but there’s a definite
problem loading shared extensions under Mac OSX 10.2.2.
If I run the following
ruby -rsocket -e1
it blows up doing the rb_define_class in Init_socket(). The problem is
that sym_tbl (in parse.y) is apparently 0x0000000. However, tracing
the value in sym_tbl just before the call to Init_socket shows it to
be perfectly valid.
Which version of Ruby have the problem? In Ruby 1.6.7 installed
with Mac OSX 10.2.2 at least, the problem couldn’t be got.
Oh man, I’ve been working there for a month - I forgot all about
them! They are definitely some smart folks. Hey, I should bring some of
my questions to them …
Incidentally, I can try duplicating the problem myself. All I know is that
Ruby 1.6.7 and CVS both made it through ./configure && make && make test
with no complaints. I found something about passing ‘–enable-shared’ to
./configure, but didn’t apply it myself.
Still can’t get Ruby to notice the fact that I have Tcl/Tk on the machine,
but that’s a different problem
if config[‘ENABLE_SHARED’] == ‘yes’ or config[“LIBRUBY”] != config[“LIBRUBY_A”]
if $enable_shared or config[“LIBRUBY”] != config[“LIBRUBY_A”]
$LIBPATH = [“$(topdir)”]
$LIBPATH.unshift(“$(libdir)”) unless $extmk or defined? CROSS_COMPILING
Incidentally, I can try duplicating the problem myself. All I know is that
Ruby 1.6.7 and CVS both made it through ./configure && make && make test
with no complaints. I found something about passing ‘–enable-shared’ to
./configure, but didn’t apply it myself.
Yes, that was what I was trying to remember. I needed --enable-shared.
Still can’t get Ruby to notice the fact that I have Tcl/Tk on the machine,
but that’s a different problem
Me too, but on Solaris.
···
On Thursday, 12 December 2002 at 14:45:04 +0900, Brian Wisti wrote:
At 12:01 PM 12/12/2002 +0900, you wrote:
–
Jim Freeze
"What do you give a man who has everything?" the pretty
teenager asked her mother.
“Encouragement, dear,” she replied.