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.
> >
> > 1) 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
> >
> > 2) In that same directory, make a subdirectory in which to build the VM:
> >
> >   $ mkdir build
> >   $ cd build
> >
> > 3) 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".


> >
> > 4) 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>