Am 15.05.2006 um 22:09 schrieb Klaus D. Witzel:
Hi Bert,
on Mon, 15 May 2006 21:18:33 +0200, you bert@impara.de wrote:
Am 15.05.2006 um 17:59 schrieb Klaus D. Witzel:
At the moment we'd be happy if it would read script files.
Which "it" doesn't? What are you trying to do?
As I wrote earlier, the main problem is, compared to the subject line, ls -l /usr/local/lib/squeak/3.9-4/ -rw-r--r-- 1 kWitzel None 310484 May 15 11:56 B3DAcceleratorPlugin.a -rw-r--r-- 1 kWitzel None 57442 May 15 11:56 PseudoTTYPlugin.a -rw-r--r-- 1 kWitzel None 97012 May 15 11:56 UnixOSProcessPlugin.a -rw-r--r-- 1 kWitzel None 50022 May 15 11:56 XDisplayControlPlugin.a -rwxr-xr-x 1 kWitzel None 2386463 May 15 12:33 squeak.exe -rw-r--r-- 1 kWitzel None 326214 May 15 11:56 vm-display-X11.a -rw-r--r-- 1 kWitzel None 98856 May 15 11:56 vm-display-null.a -rw-r--r-- 1 kWitzel None 77634 May 15 11:56 vm-sound-OSS.a -rw-r--r-- 1 kWitzel None 26792 May 15 11:56 vm-sound-null.a
That is, neither the X11 nor the null display *.so drivers are found (and the message in the subject line, the reason for my post, is printed).
Ironically, ./squeak -headless -nodisplay Squeak3.9b-7032.image and only -headless and only -nodisplay, attempts to use the X11 display driver...
"-headless" is an option of the X11 driver, so that's not that surprising.
As for loading the display modules, they have to be shared libraries suitable to be used by dlopen(). You only have static libraries, at least that's what I guess from the ".a" extension. I guess on Windows that would have to e a DLL. And even if you compile the modules as Windows DLL you might have to adjust the module loader to look for a ".dll" extension.
- Bert -
Hi Bert,
on Mon, 15 May 2006 23:57:34 +0200, you wrote: ...
"-headless" is an option of the X11 driver, so that's not that surprising.
Right you are. Now I understand why on a debian sans X11 the only option was vm-display-null (for running squeak unattended as back-end to apache), alternately vm-display-fbdev.
As for loading the display modules, they have to be shared libraries suitable to be used by dlopen().
This is exactly the point. Will have to find out how dlopen is on cygwin (google says that people use LoadLibrary on cygwin, even though dlopen is available).
You only have static libraries, at least that's what I guess from the ".a" extension.
Yes, and I couldn't convince whomsoever to make them non-static (have seen the various comments in ltmain.sh, some of which speak about cygwin).
I guess on Windows that would have to e a DLL.
Yes, if there's need to dynamically load a library the win32 people must make a .dll. But nobody here expected that cygwin just uses what is lying around (thereby putting the burden on the library dev'er). Porting an app to cygwin seems to be easy; doing the same for supportive libs seems to be the difference between platform independence and windoze...
And even if you compile the modules as Windows DLL
This would require changes to the source, beginning with - http://lists.debian.org/debian-win32/2002/08/msg00001.html and is not what we want here (have dev'ed some .dll's running on the ISAPI interface of MS' web server...).
you might have to adjust the module loader to look for a ".dll" extension.
I think we better hack the loader for not requesting vm-display-* , looks like that would save some time. And/or perhaps vm-display-custom needs to be employed for the cygwin job, starting with __declspec(dllimport).
- Bert -
Your comments (and questions!) where very valuabe to us, thank you very much.
/Klaus
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Klaus D. Witzel