John Gabriele wrote:
> On 9/13/06, Lyle Johnson <lyle.johnson / gmail.com> wrote:
>> On 9/13/06, John Gabriele <jmg3000 / gmail.com> wrote:
>>
>> > When you load an extension module, what's the mechanism that makes
>> > those C calls (the ones that call into the Ruby API) actually get
>> > connected to the currently-running instance of ruby?
>>
>> When you use the "require" method to load an extension module,
>> [snip insightful explanation]
>> Hope this helps,
> 
> Thanks for the explanation Lyle. I'm sorry, but perhaps I was unclear
> (and also still not understanding this). I'm looking to find out the
> mechanism at work *at link-edit time*, when you're building the
> extension module. I mean, what are the args necessary to pass to gcc
> to tell it that, when your code makes those rb_foo calls, those calls
> are actually supposed to bind to something besides a .so file sitting
> on your harddisk?

I'm far from an expert on dynamic linking so I can't tell you how the 
mechanism really works, but I think what you're talking about is the 
-shared option to gcc. From man gcc:

  -shared
      Produce a shared object which can then be linked with other objects
      to form an executable.  Not all systems support this option.  For
      predictable results, you must also specify the same set of options
      that were used to generate code (-fpic, -fPIC, or model suboptions)
      when you specify this option.[1]

This option is supplied automatically in the Makefile that is generated 
when you use the usual extconf.rb and mkmf.rb approach to build an 
extension.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407