I'm trying to build an up-to-date VM from source in order to get OSPP and XDCP updated for the 64 bit code base. I'm having trouble building a VM from the latest; the vm-display-X11 module will not load. I'm stumped and would appreciate some help.
Here's the situation:
$ cat /proc/version Linux version 2.4.21-144-default (root@i386.suse.de) (gcc version 3.3.1 (SuSE Linux)) #1 Fri Nov 14 00:01:36 UTC 2003
$ squeak -version 3.7b-6 #30 Mon May 2 10:55:50 EDT 2005 gcc 3.3.1 Squeak3.7 of '4 September 2004' [latest update: #5989] Linux dtlewis 2.4.21-144-default #1 Fri Nov 14 00:01:36 UTC 2003 i686 i686 i386 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-6/*.so
Squeak image is Squeak3.7 of '4 September 2004' [latest update: #5989]
I loaded VMMaker-tpr.37.mcz from Tim's site.
The platforms source is loaded from SVN as of today (June 30).
I built and installed the VM with no errors or warnings related to vm-display-X11. The vm-display-X11 module is correctly installed in /usr/local/lib/squeak/3.8a-2.
When I run Squeak I get this: $ squeak sq.image looking for module vm-display-X11 could not find display driver vm-display-X11; either: - check that /usr/local/lib/squeak/3.8a-2/vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. Aborted
I can run the VM under GDB, and I think I see the dlopen() attempting to open the /usr/local/lib/squeak/3.8a-2/vm-display-X11 file, and failing as if the file were not there.
But I can copy a vm-display-X11 file from some earlier build into the installation directory, and the VM finds and loads it (but crashes on account of it being a different version). So it does not appear to be a path problem, the VM is looking it the right place, and finding a vm-display-X11 file there.
It appears that there is something about the vm-display-X11 file itself that causes it to be unloadable (it's world readable and world executable, so that's not it). The file itself looks fine:
$ ls -l /usr/local/lib/squeak/3.8a-2/vm-display-X11 -rwxr-xr-x 1 lewis users 150331 2005-06-30 11:26 /usr/local/lib/squeak/3.8a-2/vm-display-X11 $ file /usr/local/lib/squeak/3.8a-2/vm-display-X11 /usr/local/lib/squeak/3.8a-2/vm-display-X11: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
And the module built without errors and warnings, so I'm thinking it may be something that has changed recently in the source tree.
I feel like Mr. Jones, something is going on but I don't know what to do. Any tips?
Thanks,
Dave
On Thursday 30 June 2005 6:43 pm, David T. Lewis wrote:
It appears that there is something about the vm-display-X11 file itself that causes it to be unloadable (it's world readable and world executable, so that's not it). The file itself looks fine:
$ ls -l /usr/local/lib/squeak/3.8a-2/vm-display-X11 -rwxr-xr-x 1 lewis users 150331 2005-06-30 11:26 /usr/local/lib/squeak/3.8a-2/vm-display-X11 $ file /usr/local/lib/squeak/3.8a-2/vm-display-X11 /usr/local/lib/squeak/3.8a-2/vm-display-X11: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
And the module built without errors and warnings, so I'm thinking it may be something that has changed recently in the source tree.
I feel like Mr. Jones, something is going on but I don't know what to do. Any tips?
Try running it under strace to see what's happening. Also, you can turn on debug messages that should indicate the loader's progress.
strace -o sq.out -etrace=file,process /usr/bin/squeak -vm-sound=null
on my system results in the attached trace.
On Fri, Jul 01, 2005 at 12:44:36PM -0700, Ned Konz wrote:
On Thursday 30 June 2005 6:43 pm, David T. Lewis wrote:
It appears that there is something about the vm-display-X11 file itself that causes it to be unloadable (it's world readable and world executable, so that's not it). The file itself looks fine:
$ ls -l /usr/local/lib/squeak/3.8a-2/vm-display-X11 -rwxr-xr-x 1 lewis users 150331 2005-06-30 11:26 /usr/local/lib/squeak/3.8a-2/vm-display-X11 $ file /usr/local/lib/squeak/3.8a-2/vm-display-X11 /usr/local/lib/squeak/3.8a-2/vm-display-X11: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
And the module built without errors and warnings, so I'm thinking it may be something that has changed recently in the source tree.
I feel like Mr. Jones, something is going on but I don't know what to do. Any tips?
Try running it under strace to see what's happening. Also, you can turn on debug messages that should indicate the loader's progress.
strace -o sq.out -etrace=file,process /usr/bin/squeak -vm-sound=null
Thanks Ned, that was just the tip I needed.
The strace shows the /usr/local/lib/squeak/3.8a-2/vm-display-X11 file being opened, followed shortly thereafter by this:
open("/usr/local/lib/libXext.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
I remember this coming up before as a configuration glitch on some versions of Linux. I'll get it straightened out on my system and report back if there is anything interesting to add.
Dave
Ian,
While trying to debug a problem in loading vm-display-X11, I found that errors in vm-display-X11 were silently ignored in the module loading process.
Here is a patch for sqUnixExternalPrims.c that prints the dlerror() message on standard error if a shared module file exists but dlopen() fails to open it. This prevents the situation where the VM fails to load a module due to a real problem in the module file, then proceeds to look for the module in a bunch of other places without informing the user that something bad may have happened.
This is just for the dlopen() in tryLoading(). An error message was already in place to cover dlopen() errors in ioLoadModule().
Following is an example of console output in a case such as this:
lewis@dtlewis:/tmp/sq/Squeak64BitPort/images/build32> squeak dlopen() failed to load module /usr/local/lib/squeak/3.8a-2/vm-display-X11 /usr/local/lib/squeak/3.8a-2/vm-display-X11: undefined symbol: oopAt could not find display driver vm-display-X11; either: - check that /usr/local/lib/squeak/3.8a-2/vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. Aborted
I have attached a diff file as well as the patched source file.
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Ned Konz