Hi,
The only other thing I can thing of right now is to check and make sure that you are running the VM that you built, and not by accident running some left over bits of the last installation. In particular, a package that you installed from the FreeBSD distribution might have installed a /usr/bin/squeak script, whereas the local build would have installed in /usr/local/bin/squeak.
So double check that you are running /usr/local/bin/squeak and not /usr/bin/squeak. On my box it looks like this:
$ type squeak squeak is hashed (/usr/local/bin/squeak)
$ squeak -version 4.13.8-3183 #1 XShm Sun Dec 14 12:04:38 EST 2014 /usr/bin/cc Linux LexIT-Gazelle-Professional 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux plugin path: /usr/local/lib/squeak/4.13.8-3183 [default: /usr/local/lib/squeak/4.13.8-3183/]
A few other thoughts in line below.
Dave
On Tue, Dec 16, 2014 at 05:15:57AM +0000, B J wrote:
<snip>
If you think that the module is not being built at all, take a look at the config.h file in your build directory. That is the output of the cmake configure process, and if there is some issue related to locating the build libraries, you will probably see evidence of it in config.h. Look for definitions that are commented out, but maybe should not be.
Nothing that I might recognize stood out for me.
OK, so the display module is being built, and after "make install" you would find it installed as /usr/local/lib/squeak/4.13.8-3183/so.vm-display-X11
Note, the "so.xxxx" naming convention is part of the installation process, so don't worry about that. If you can build the VM and install it, the naming will take care of itself.
I'm not sure which source package you are starting with, but here is a simple recipe for building the latest from Subversion.
- Start with an empty directory, then get the latest versions of all the
platforms sources and the VMMaker generated sources:
$ svn co http://squeakvm.org/svn/squeak/trunk/platforms $ svn co http://squeakvm.org/svn/squeak/trunk/src
- In that same directory, make a subdirectory in which to build the VM:
$ mkdir build $ cd build
- Copy the attached Makefile into your build directory.
It wanted to install a 64-bit version. I haven't attempted to edit to file for 32 bits.
The 64-bit version should be fine (I use the 64-bit VM regularly and no longer bother building a 32-bit version for my own use). It's possible that your image is making use of some plugin that still has 64-bit issues, but I think this is not likely.
If you want to build in 32-bit mode, add "-m32" to the CFLAGS in the Makefile, then "make clean; make; sudo make install".
- build the VM, and install it if you get plausible results.
$ make $ sudo make install
I used:
/root/Desktopo/squeak/platorms/unix/cmake/configure
followed by:
make make install
I got the same results as before, though there was a squeakvm.core file in my build directory as a result of the crash.
There is a vm-display-X11 directory in my build directory, but when I open it, there's a directory named "CMakeFiles". Inside that, is "vm-display-X11.dir" and, going further, it looks like its a continuing series of nested directories.
That is normal CMake build stuff. The so.vm-display-X11 file that is installed after "make install" is the only one that matters, and it should be activated when you run the VM normally (/usr/local/bin/squeak myimage).
This makefile is what I use on Linux, so you may need to fiddle around with the CFLAGS, or add additional "--without xxxx" options to exclude modules that give you problems, but otherwise I think it should work.
I haven't tried that yet, partly because I don't know enough about what's going on.
I guess one more thing that would be worth trying is to turn off compiler optimization. There are a lot of versions of gcc floating around and they are not all equally reliable. Try setting optimation level to zero like this in the Makefile that I sent (that's a zero in the "-O0"):
CFLAGS_PARAM="--CFLAGS='-O0 -D_FILE_OFFSET_BITS=64'"
The mystery continues.
<snip>