www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Accessing extern variable in Ruby DLL

reply Jordan Miner <TheUndaunted NOSPAM.gmail.com> writes:
Hello,

I recently wrote a binding to Ruby’s extension API , and today finished writing
a simple extension using it. But I ran into something strange. (I also had a
problem compiling the DLL since I use Tango, but searching the newsgroup
yielded the solution.)

Ruby’s API has rb_cObject, rb_cString, etc. as global variables that it sets to
the Object class, String class etc. In ruby.h, they are defined as

extern unsigned long rb_cObject;

so in my binding I have

extern uint rb_cObject;

But when I try to use rb_cObject from my extension, it is not the right
value... I think rb_cObject should equal rb_eval_string("Object"), but it does
not. (Using the wrong value causes an access violation.)

I produced an OMF import library for Ruby’s runtime DLL by using coff2omf on
the COFF import library that ships with it. I'm linking my extension with this
import library.

If I remove the extern from my binding, I get a multiple definition error, so I
must be linking with the variable in the DLL? But it seems the value is wrong.
I’ve worked around this by calling rb_eval_string("Object") instead, but I’m
really curious what could be happening here. Using rb_cObject is the usual way
of referring to the Object class in C extensions, and I want to make sure my
binding is correct. Could it be because the DLL was compiled with Visual Studio
and my extension is in D?

Any ideas?
Jan 16 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 17 Jan 2009 06:30:35 +0300, Jordan Miner
<TheUndaunted nospam.gmail.com> wrote:


 Hello,

 I recently wrote a binding to Ruby’s extension API , and today finished  
 writing a simple extension using it. But I ran into something strange.  
 (I also had a problem compiling the DLL since I use Tango, but searching  
 the newsgroup yielded the solution.)

 Ruby’s API has rb_cObject, rb_cString, etc. as global variables that it  
 sets to the Object class, String class etc. In ruby.h, they are defined  
 as

 extern unsigned long rb_cObject;

 so in my binding I have

 extern uint rb_cObject;

 But when I try to use rb_cObject from my extension, it is not the right  
 value... I think rb_cObject should equal rb_eval_string("Object"), but  
 it does not. (Using the wrong value causes an access violation.)

 I produced an OMF import library for Ruby’s runtime DLL by using  
 coff2omf on the COFF import library that ships with it. I'm linking my  
 extension with this import library.

 If I remove the extern from my binding, I get a multiple definition  
 error, so I must be linking with the variable in the DLL? But it seems  
 the value is wrong. I’ve worked around this by calling  
 rb_eval_string("Object") instead, but I’m really curious what could be  
 happening here. Using rb_cObject is the usual way of referring to the  
 Object class in C extensions, and I want to make sure my binding is  
 correct. Could it be because the DLL was compiled with Visual Studio and  
 my extension is in D?

 Any ideas?



Try the following:

extern(C) extern uint rb_cObject;
Jan 16 2009
parent Jordan Miner <TheUndaunted NOSPAM.gmail.com> writes:
Denis Koroskin Wrote:


 Try the following:
 
 extern(C) extern uint rb_cObject;
 



I forgot to mention it, but I already have extern(C): at the beginning of the
file.
Jan 17 2009
prev sibling parent reply torhu <no spam.invalid> writes:
On 17.01.2009 04:30, Jordan Miner wrote:

 extern unsigned long rb_cObject;

 so in my binding I have

 extern uint rb_cObject;



For accessing variables in a DLL, you need to do it like this:

export extern (C) extern uint rb_cObject;
Jan 17 2009
parent Jordan Miner <TheUndaunted NOSPAM.gmail.com> writes:
torhu Wrote:


 On 17.01.2009 04:30, Jordan Miner wrote:

 extern unsigned long rb_cObject;

 so in my binding I have

 extern uint rb_cObject;



 For accessing variables in a DLL, you need to do it like this:
 
 export extern (C) extern uint rb_cObject;
 



That worked, thank you! I already had extern(C): at the top of the file, but I
hadn't thought of adding export.
Jan 17 2009