On Sat, Dec 21, 2002 at 05:05:05PM -0500, Phil Hargett wrote:
> I typically build all plugins internal, so there's no *.so file to check.
> Further, I looked in the directory containing my running instance of
> squeak (also as a vm), in /usr/local/lib/squeak/3.2-6, and my build
> directory and could no such *.so.

You still could be loading an external plugin without knowing it. Try
evaluating "Smalltalk listLoadedModules" and see what it tells you. If
the entry for UnixOSProcessPlugin has an "(e)" after it instead of "(i)",
then you have loaded an external UnixOSProcessPlugin.so over the top of
your internal plugin. If so, find the UnixOSProcessPlugin.so file that is
getting loaded and get rid of it. If that's not the case, then I'm just
confused.

> Oddly, I also noticed that although my build directory does have an
> UnixProcessPlugin.c, it does not have the usual subdirectory just for this
> plugin.  Is that correct?  Further, when I check the VMMaker configuration
> I've used to build this VM, I notice that the plugin that appears is
> UnixProcessPluginNoInThisSession--what's that?

VMMaker does the right thing (tm), so don't worry about that. As far at
the UnixProcessPluginNoThisSessionAvailable listing in VMMaker, that's
OK too. That's just the name of the class which generates the actual C
program file. Actually sort of a hacky way I used to get conditional
code generation, and I'll get rid if it some time soon.

Just to be safe, you might want to clean out your build directory completely
and regenerate everything from scratch.

> I don't think things are entirely broken, as I am able to safely clone my
> running squeak instance, as well as fork headless images.  Further, on a
> prior build of this VM I know I have (de)capitated images without issue.

Hmmm, I'm not sure how that could be working if the sunit tests fail.

> Hope the info helps! :)

Yes, much appreciated. Let me know what "Smalltalk listLoadedModules" has
to say about it.

Dave