Re: Using Tcl_*ObjCmd in extensions

Helmut Giese wrote:
>
> Uh? Your linker complains about 'unresolved externals'?

No, my linker doesn't complain (that is when doing all build steps
natively). It's just that the shared object that the linker produces
still has unresolved symbols.

I don't think
> this ever happened to me. Show your setup, and I'm sure people will
> help you straighten things out.
>
>

OK, try the following (it uses the Tcl_ClockObjCmd as an example, but
you can pick any Tcl_*ObjCmd):

#include <tclInt.h>

int
Myclock_Init(Tcl_Interp *interp) {
        int result;
        
        if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
                return TCL_ERROR;
        }

        /* create argument vector */
        Tcl_Obj *newObjv[2];
        newObjv[0] = NULL; /* unused, would normally hold
                                the name of the Tcl command;
                                "clock" in this case */
        newObjv[1] = Tcl_NewStringObj("clicks", -1);
        Tcl_IncrRefCount(newObjv[1]);
        result = Tcl_ClockObjCmd((ClientData)NULL, interp, 2, newObjv);
        Tcl_DecrRefCount(newObjv[1]);

        return result;
}

And compile like this, and display symbol information:
gcc -DUSE_TCL_STUBS -c -o myclock.o myclock.c
gcc -shared -o myclock.so myclock.o -ltclstub8.4
nm -a myclock.so

In my case, I see that all symbols have been resolved in the link step,
except for "Tcl_ClockObjCmd".

Next, load the shared object into tclsh or wish:
% load myclock.so

and you'll see that it doesn't complain about any unresolved (or should
I say undefined?) symbols, and that it works as intended.

Now, normally if I load any shared object that has unresolved
references, I get a complaint/error. Not in this case.

Why not?

Thanks for your attention,

Erik Leunissen
==============

>>This does not "feel good". However, when dynamically loading the shared
>>library, there is no complaint (which I does surprise me), and the
>>library's functionality works fine.
>>
>>Still, I'm unsure whether this is evil.
>
> Quite the contrary: It's a blessing. (hm, Xmas time showing thru ? :)
> )
>
>
>>Could anybody expand a bit why
>>it is(n't)?
>
> Well, you have what is called a 'stubs table' - an array of pointers
> to the 'real' functions, which get filled in during intialisiation of
> the stubs mechanism.
> When you call a function Tcl_Foo (and have USE_TCL_STUBS #defined)
> this call is converted (via a macro) to calling the function pointer
> at, say, slot 37, which points to the 'real' Tcl_Foo. Tcl_Bar is
> converted to use slot (stub) 38, etc.
> All this is standard C - cleverly thought out, but still nothing
> magic. Have a look at how the stub table is initialised, and - once
> you grok the mechanism - you'll wonder why you didn't think of it
> yourself. :)
> HTH
> Helmut Giese

-- 
   leunissen@       nl | Merge the left part of these two lines into one,
e.          hccnet.   | respecting a character's position in a line.