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