I found the reason for the linking confusion!

On Tue, 22 Aug 2000, you wrote:

> On some systems you can LD_LIBRARY_PATH, LD_SEARCH_PATH, etc., until
> the cows come home and you're *not* going to persuade the linker (note
> for anyone who still hasn't realised: we're talking about /bin/ld, NOT
> about /lib/ld.so) to look where you want it to.  On these systems you
> also seem to be forced to use "-l" to link against the plugins (they
> don't understand how to deal with ".so" files on the linker command
> line), which means the plugins must be installed in a standard
> directory and be called "libXXX.so.X[.Y[.Z]]".

Wait a moment. None of the external modules have to be existent at VM
compile time, because they get loaded via dlopen() anyway.

> (Aside: I'm still waiting for someone to explain to me why we need to
> keep an explicit table of primitive function addresses in the VM at
> all [which is the unique cause of all of these problems], when we
> could just use the "original" module mechanism to find any "internal"
> plugins by gazing into the navel of the executable itself [which it
> did already, to find the "intrinsics"].  Or did I miss a good logical
> argument against this?)

I'm afraid so. The explicit table is for looking up internal primitives
ONLY. These adresses may get overwritten at runtime if an external
module is present.

I'm not quite sure we have a common assumption about the module loading
process yet: The addresses of the internal functions are determined at
compile time (in sqNamedPrims.h) and don't need any runtime lookup at
all. The "intrinsics" aren't loaded at all (hence my patch to make them
be loaded for FFI calls to system functions). The adresses of external
functions are looked up at runtime and added to the module table. So, when
you build psqueak you must use a different sqNamedPrims.h that does not
list all the plugin functions! There's no need to link the plugins with
the VM at all!

Oh, wait again. Did you actually notice all the module files are
dependend on being generated for internal/external access?! Even the
function names are different. For internal functions, it's
"Modulename_Functionname" to prevent name clashes. For external modules,
it's only "Functionname" which get's looked up in module "Modulename".
(IMHO we should change the generated code so it only depends on one flag
being defined.)

So I guess it's back to work for you ;)
OTOH this should again simplify the building process :-))

-- Bert