Ian Piumarta wrote:

> So I _still_ don't know why the table is needed -- except to associate
> a numeric primitive index with a named primitive (which I would
> consider an ugly performance hack and certainly not a "crystalisation
> of style" ;-).
That was Andreas' way of making an old 'numbered-prim' image work with a
newer 'named-prim' VM. The table can be removed someday. Nothing to do
with performance.
> 
> Unless there is a platform somewhere on which it is impossible to
> dlsym() into the executable itself? 
Acorn. Any no-OS machine. EPOC, I think.


> So this is the problem.  I have a *complete* list of the functions in
> there.
Yes, that would be a problem. Remember you have to generate the sources
to have each plugin either internal or external and (at the moment) you
can't use 'internal module' code for an external module. I'm reasonably
sure you could do some macros to make the module code simply recompile
with a flag change. Generate a couple each way and compare and contrast
for full enlightenement.


> They seem to work fine "out of the box" in both contexts.  But it's
> entirely possible that there are zillions of external symbols being
> patched up "silently" by ld.so.
That seems to be the case. Evil, over 'helpful', ld. hiding problems
until it chooses to bite your butt.