From: John Gabriele <jmg3000@...>
Date: 2006-09-14T05:53:15+09:00
Subject: Re: building extension modules, and linking

On 9/13/06, Tim Becker <a2800276@gmail.com> wrote:
> > But when we're building an extension module, how to you do tell GCC
> > (at link-edit time) that you want your code to link to (at runtime)
> > what's already loaded and running -- that is, to link to the ruby
> > interpreter -- rather than to some shared lib somewhere?
>
> I think the point you're missing is that the runtime the interpreter
> loads your extension, not the other way around.

Right. But, before that -- at link-edit time, when I build the
extension module with "gcc -shared", how exactly do I patiently
explain to gcc, "yes there's functions in this code that start with
rb_, yes they're described in ruby.h, no you may not look at the code
they'll be calling at runtime. Sorry."? I guess I'm only familiar with
the common case where you're telling gcc to link up with other libs
(via "-L" to tell it non-standard places to look, and "-l" to specify
the shared libs) -- at link-edit time, doesn't gcc always have to see
the code that *your* code will later be calling?

> Else the extension
> would just pop into existence and then stumble around looking for a
> running interpreter.
>
> If you're interested in how the interpreter goes about loading your
> extension technically, search around for 'dlopen' (at least on a Linux
> system).
>

Yes. I've glanced at dlopen in the past. C code uses it when it wants
to load other libs at runtime. It looks to me like dlopen asks the OS
for a given object, and then the OS hunts around, finds it, loads it,
and then hands back some kind of file pointer to it. So, I'm guessing
ruby uses dlopen to load extension modules.

Thanks,
---John