On Thu, Feb 12, 2004 at 10:29:56PM -0800, Julian Fitzell wrote:
> David T. Lewis wrote:
> > 
> > I really don't know what's going wrong here. You should be seeing one
> > (not three) attempts to load the plugin, followed any number of calls to
> > ioFindExternalFunctionIn() for each of the primitives being loaded.
> > 
> > I don't know if it will help, but I've attached a log file from my Linux
> > Squeak set up similarly to what you described for your Solaris system
> 
> Hmm... your output certainly seems healthier than mine. :)
> 
> It seems like the difference is that mine never gets past the 
> initialiseModule() call (though that function *is* called).  It seems 
> like it doesn't encounter an error (and thus it doesn't note the plugin 
> is unavailable), but nor does it seem to complete the task well enough 
> to continue calling other functions...
> 
> Hopefully somebody will have some ideas... I'm thinking I'd better try 
> making my own plugin that just does the file locking primitive - at
> least to see if it works.

A couple other things you might try for debugging: You might try just
deleting all the primitives in UnixOSProcessPlugin that are not directly
related to file locking. Just basically strip it down until something
starts working.

Another thing you could try is to disable OSProcess on the image side so
it never tries to call the OSPP plugin on image startup. Then you could
call primSizeOfInt with that being the first access into OSPP, and maybe
have a better chance of seeing the problem. I don't have time to try
this, but to disable OSProcess startup, just hack the #startUp: methods
in classes ThisOSProcess and OSProcessAccessor, and stop the background
process with "OSProcess accessor grimReaperProcess terminate". Restart
the image, and it should start up without trying to load OSPP, then
try your primSizeOfInt test.

HTH,
Dave