On Sun, Dec 14, 2014 at 03:02:32PM +0000, B J wrote:

<snip>

Thanks.

...

There's a couple things that may go wrong:

It's possible it was not built because of missing header or library files.

It's also possible the module's file name is different (e.g. on Linux it is so.vm-display-x11)

I've noticed that with FreeBSD when I tried installing Squeak from the repository.

so you might have a look in the vm's lib directory for

...

what the actual name is.

It said it was looking for vm-display-x11.so, but if so.vm-display-x11 is what's produced, I'm assuming that an error would result.

...

Also, if you did not run "make install" you will have to pass the actual directory name for the plugins on the vm's command line.

The instructions suggest running "make" first, checking out the results first, and then running "make install". I didn't go further than just "make" because of the error.

...

Finally, even if the VM finds the module, it may fail to load if some dependent library is missing. On Linux I can check with "ldd pluginfile", not sure what the equivalent BSD command is.

I haven't tried that yet.

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.

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.

4) build the VM, and install it if you get plausible results.

$ make $ sudo make install

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.

HTH, Dave

David, BJ

If this does work, we can take the CMakeLists.txt files and other cmake files and port them directly to the CMakeVMMakerSqueak BSD configuration so that we have a repository of this work.

In CMakeVMMakerSqueak--it is CMake that drives the process, and Smalltalk just encapsulates what works.

I expect to have a first release tomorrow (was going to be today, but it turned out to be a warm, beautiful day and I got distracted (: )

cheers,

tty.

---- On Sun, 14 Dec 2014 12:16:40 -0800 B J &lt;quarterwavevertical@gmail.com&gt; wrote ----

Thanks for the info.

&gt; If you think that the module is not being built at all, take a look at the &gt; config.h &gt; file in your build directory. That is the output of the cmake configure &gt; process, &gt; and if there is some issue related to locating the build libraries, you will &gt; probably &gt; see evidence of it in config.h. Look for definitions that are commented out, &gt; but &gt; maybe should not be. &gt; &gt; Note, the "so.xxxx" naming convention is part of the installation process, &gt; so &gt; don't worry about that. If you can build the VM and install it, the naming &gt; will &gt; take care of itself. &gt; &gt; I'm not sure which source package you are starting with, but here is a &gt; simple &gt; recipe for building the latest from Subversion.

I was using the compressed file on:

http://squeakvm.org/unix/index.html

&gt; &gt; 1) Start with an empty directory, then get the latest versions of all the &gt; platforms sources and the VMMaker generated sources: &gt; &gt; $ svn co http://squeakvm.org/svn/squeak/trunk/platforms &gt; $ svn co http://squeakvm.org/svn/squeak/trunk/src &gt; &gt; 2) In that same directory, make a subdirectory in which to build the VM: &gt; &gt; $ mkdir build &gt; $ cd build &gt; &gt; 3) Copy the attached Makefile into your build directory. &gt; &gt; 4) build the VM, and install it if you get plausible results. &gt; &gt; $ make &gt; $ sudo make install &gt; &gt; This makefile is what I use on Linux, so you may need to fiddle around with &gt; the &gt; CFLAGS, or add additional "--without xxxx" options to exclude modules that &gt; give &gt; you problems, but otherwise I think it should work.

I think this might help. I'll see what happens with this.

&lt;snip&gt;

Had the same - probably - issue a few weeks ago building under Raspbian.

So far as I could work out the problem is to do with the location of GL library and headers. In Raspbian I was loading the mesa-common-dev in order to get the openGL stuff. Without it you can build a working VM but without the B3DAcceleratorPlugin. With it the config ‘passes’ the test for the presence of the GH.h header(s) but the resultant vm-display-X11.so isn’t correctly linked to the libGL and so won’t come up.

You *can* force a preload to get around this. For example `LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libGL.so.1` stuck in front of the exec “$Bin/squeak….. stuff seemed to solve the problem pro tem.

Take a look at your squeak.stack.v3/build/config.log (or close equivalent) to see if this is the problem. Search for something like `checking GL/gl.h usability` and look at the output after that. If it doesn’t report `fatal error: GL/gl.h: No such file or directory` then see if any of the compile/link stuff after that is trying to use -lGL as in libGL. My guess is that you have GL.h but the path to libGL is not correct. I don’t know how to fix that. My best answer was to remove the mesa-common-dev package and sidestep it for now.

AutoBlech and it’s kin are crimes against nature.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never forget: 2 + 2 = 5 for extremely large values of 2.

Hi David,

CMakeVMMakerSqueak wraps Ian's CMake code

Ian Piumarta ditched his earlier "autoblech" build and replaced it with a much better CMake process. I think this was about a half dozen years ago (!). Presumably he did that in part because of the problems that you are now experiencing. I also recall that there were some real issues with 32 and 64 bit library management that were intractable with autotools at the time, and that the CMake folks seem to have addressed reasonably well.

Personally, I have very little patience for any of this stuff, so I am happy to make use of the CMake build that Ian provided. It works well, and has not had any of the 32/64 bit library management problems that autotools were encountering at that time. It also works on my new Ubuntu laptop with who knows what sort of compiler and build tools (more than I can say for the autotools builds).

It is a complete mystery to me why anyone would want to reinvent this particular wheel.

(with some small differences in plugin-approach that can be standardized via refactoring if needed).

I have differed with Pharo team in that CMAKE DRIVES THE PROCESS. We start with a working CMake and just encapsulate that in Squeak.

Ian's CMake code lives in CMakeVMMakerSqueak in the same way that the VM codebase lives in Squeak.

I look forward to discussing once I get the (minimal) beta-release for linux32 out today (which should be readily portable to Tim Rowledge's ARM platform and BJ's BSD platform and the gentleman who wants a SunOS port) .

Here is the short version of the project.

Stage 1. get Pharo code working on squeak--this worked fine and was easy. Stage 2. Support Eliot's needs for number of platforms, languages, vm's and build types. I attempted to bolt this on with possibly the most ridiculous use of a Trait ever attempted in world history. That approach was abandoned when I discovered that a massive Trait is not loadable via monticello unless one has several decades available for download time.

Stage 3. was Study Ian's code and CMake--(light bulbs go light up in tty's brain). Stage 4 was attempt to do both Pharo and Squeak and Ian's CMake with existing framework. Stage 5. Abandon attempt to shoe-horn Ian's CMake into Pharo. Stage 6. Implement CMake Template approach which are small classes that wrap CMake constructs and that output their contents to a stream (think Seaside Components) Stage 7. Compare 6 output to Ian's code. They are pretty much tit-for-tat.

This tool just generates CMake. If there are problems with configuration and compilation, they are addressed by modifying the generated CMake. The resulting edits can then be incoorporated into an existing CMakeVMMakerSqueak Configuration or ported to a new configuration.

To use this tool, ONE MUST THINK IN CMAKE, which is what Ian did, which is how this project will progress.

Did I mention the tool is CMake driven ?

(:

cordially,

tty

On 14-12-2014, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:

Ian Piumarta ditched his earlier "autoblech" build and replaced it with a much better CMake process. I think this was about a half dozen years ago (!).

I think it was a little after Cog was split off, which explains the dual insanity we have now. I really hope tty is getting close to producing a working CMake setup we can accept to replace the autoblech for Cog. When I offered the bounty for doing this (a year ago!) I imagined that somebody with some relevant experience would simply copy across the plain interp related CMake files and extend them, maybe add a few more bits for the extra files Cog brings in, sprinkle some fairy dust and *foom*! done.

But in the end I don’t care how it’s done, just that it *is* done.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim this blank intentionally left spaced

On 16-12-2014, at 3:49 PM, gettimothy gettimothy@zoho.com wrote:

Hi Tim.

think it was a little after Cog was split off, which explains the dual insanity we have now. I really hope tty is getting close to producing a working CMake setup we can accept to replace the autoblech for Cog. When I offered the bounty for doing this (a year ago!) I imagined that somebody with some relevant experience would simply copy across the plain interp related CMake files and extend them, maybe add a few more bits for the extra files Cog brings in, sprinkle some fairy dust and *foom*! done.

But in the end I don’t care how it’s done, just that it *is* done.

tim

Do you have the time to attempt generating an ARMv6 CMake configuration? I will be happy to walk you through the process its not hard and pretty intuitive.

We can try; and a written explanation intended for someone that hasn’t used it before is a pretty good exercise in testing that it actually works.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MONAGE A TROIS - I am three years old

Hi,

My goal is that a complete newbie can follow the instructions and be able to get an entire VM producing image and compile the thing just by following help starting with a bash shell script that downloads and configures an image for VM production followed by what you will be working with above.

Feedback from you (and others) on using the thing will be incorporated into that.

here's someone who once (as in one single time) built a Squeak 3.7 Windows VM, forgot everything and is eager to test and report.

What do I have to download to start? I'd like to start on a Raspberry Pi but also have an Ubuntu 12.04 Server without X where I use RFB in Squeak.

Cheers,

Herbert

Hi Tim,

nowadays I want to build on Linux (Raspberry Pi). So my question was where I could get your HelpBrowser pages as far as they are done. I only found CMakeVMMaker on Squeaksource but it was too dated to contain your HelpBrowser additions. I see this as part of learning some Linux.

Maybe you could send me that bash script you mention below. I would study that, run it and then try to follow your CMakeVMMakerSqueakStartHereHelp. And if that's not available for RasPi I would use my Ubuntu server in Text mode where I run Squeak headless through RFB.

I'm less interested in Windows at the moment. Especially I don't have (and don't want to get) Visual Studio. It's just that back then I did it on Windows using the process that is outlined at squeakvm.org. I was just trying to qualify as newbieish enough to give useful feedback by stumbling into everything you implicitely assume a newbie knows but doesn't know.

Cheers,

Herbert

Am 17.12.2014 um 15:38 schrieb gettimothy:

Hi Herbert.

Thanks, you have prodded me into realizing that I need to write Help on how to do a manual setup. I will do that now and get back to you.

I have a bash shell script that will download and completely configure an image for both VMMaker code generation and CMakeVMMakerSqueak cmake generation. However, when I tried to run it in cygwin on my dos partition, it did not work.

For Windows, there is additional platform work to be done. I was going to do it after the *nix release is up and on auto-pilot.

If you have the time and energy and would like to contribute, I can walk you through the steps on setting up what I call a "Platform Configuration" which is basically a superclass that sets up "platform specific global information'

In *nix this has been done. On Mac and Windows, what is in place is a port of what exists in pharo's CMakeVMMaker package to Squeak and it has not been tested.

What follows is a longer explanation of what I mean.

CMakeVMaker(Squeak) stores CMake files in "Configurations". There are several layers to them.

CPlatformConfigForSqueak <--1. GLOBAL superclass for CMakeVMakerSqueak configurations. SqueakUnixConfig SqueakMacintoshConfig SqueakWindowsConfig <--2. Provide OS Specific CMake output. Linux32ARMv6Config SqueakWin32x86Config SqueakWin32x86Config <--3. Platform specific Configurations SqueakBSD32x86Config <--3.a Platform specific Configuration SqueakSunOS32x86Config <--3.b Platform specific Configuration ...... <--3...... Platform specific Configuration Linux32x86Config <--3.z Platform specific Configuration Linux32x86SqueakCogV3Config <--4 Platorm Specific [Language]. [VM] [Memory Model] Configuration this is what generates CMake to build Squeak Cog V3 on this platform

The *Nix platform is just a matter of building out the level 4 Configurations. The Mac and Windows platforms need building out and testing at level 3.

What that means is "CMake Drives The Process" and whatever Windows specific template is correct CMake needs to be encapsulated in the corresponding level 3 Configuration.

On the *Nix platforms, the CMake Template is basically Ian Piumarta's work from the Standard Interpreter with only some cosmetic differences.

level 4. Configurations just specify build time stuff--where the source is, what compiler flags, linker flags, pre-processor flags, definitions--they are basically the equivalent of Eliot's MVM files in the Cog/build.xyz/lang.vm.mm/buildtype/mvm tree.

On the Windows and Mac platforms, I do not know if Ian's work is what we need or if something better can be done that is Windows specific and utilizes the Windows based build suite. (fwiw, I think it would be really cool to see people stepping through VM code using Visual Studio...)

So, to summarize.

On the Windows and Mac platforms are NOT at a level 4 stage like Linux is. If you would are interested, I can walk you through the dev process--its quite easy--its the equivalent of generating Seaside Components to build a web-page. You figure out what you want the web-page to look like and then generate the components you want to get the output you want. It is work, however and I don't know if you want to spend time on it.

cheers.

tty.

I’m looking forward to this. Yesterday, in a process of debugging my systemd experiments [1], I compiled an interpreter vm. I mention this, because you are talking about making the process easy. David T. Lewis made a fire-and-forget script that is the easiest way I’ve seen so far to compile a vm on Linux. [2] I’m looking forward to CMake classes for building a Squeak vm..

Chris

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-July/179015.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-July/179015.html [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-October/166038.h... http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-October/166038.html It didn’t seem to compile an X11 plugin, so I copied one from an earlier build. And I had to pull the no-sound plugin from out of its folder, so the vm could find it. The squeak.sh script wasn’t working.

On Dec 17, 2014, at 8:05 AM, gettimothy gettimothy@zoho.com wrote:

Hi Tim.

...

...

We can try; and a written explanation intended for someone that hasn’t used it before is a pretty good exercise in testing that it actually works.

HelpBrowser openOn: CMakeVMMakerSqueakStartHereHelp <--done. Gives an example workflow for generating a CMake build tree and compiling the VM. HelpBrowser openOn: CMakeVMMakerSqueakStepByStepNewConfigurationHelp <--first draft almost done, should get you to the point where its a matter of setting CFlags, Libs, Definitions etc, for your Platform and then buildType.

Top menu->Help->CMakeVMMakerHelp includes the above and other help work I will be editing.

My goal is that a complete newbie can follow the instructions and be able to get an entire VM producing image and compile the thing just by following help starting with a bash shell script that downloads and configures an image for VM production followed by what you will be working with above.

Feedback from you (and others) on using the thing will be incorporated into that.

I would start with the StarHereHelp and just generate a cmake tree using the example Builder and Configuration.

Once you have generated the CMake tree, the (too verbose, first-draft) NewConfigurationHelp in your case boils down to copying an existing configuration and making some minor modifications to it.

Please note that I have only built out the #build buildType--I will be building out the build.assert, build.debug, etc....buildTypes when the Help is done and I have resolved NoDbgRegParms issue on my platform for those buildTypes.

cheers.

tty.

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>

On Wed, Dec 17, 2014 at 06:51:29AM +0000, B J wrote:

I decided to do a fresh installation of FreeBSD 10.1, complete with Mate as desktop and Slim as the login manager. I then downloaded the necessary files using subversion and things got interesting.

I noticed after configuring the source code that there was a warning from cmake about there not being a CMakeLists.txt file in:

/root/Desktop/squeak/platforms/unix/npsqueak

I think that is a harmless warning, so you can ignore it.

Apparently, CMakeLists.txt has to be in all input directories but earlier versions skipped it. But, the current version of cmake apparently won't allow it unless Policy CMP0014 is set. I surmised that by setting that parameter to OLD, I could get around it.

After setting that and then running "make", it appears that everything was built. I got no errors and some warnings, leading me to believe that the parameter was a key factor.

The so.vm-display-X11 plug-in now exists in:

/root/Desktop/squeak/build/vm-display-X11

so that problem appears to be solved. However, if I run:

/root/Desktop/squeak/build/squeakvm

it can't find it unless I specify that plug-in's location using the "plugins" parameter to specify its path. Now it complains that squeak can't find a sound driver.

What do I do now?

Please advise. Thanks.

Just install it and give it a try. Do "sudo make install", and run /usr/local/bin/squeak yourimage.image

Are you doing this all under a root user ID (I notice your build directory is under /root)? Bad idea, but you can skip the "sudo" part if you are already root.

Dave

On Thu, Dec 18, 2014 at 03:23:31AM +0000, B J wrote:

<snip>

...

...

I noticed after configuring the source code that there was a warning from cmake about there not being a CMakeLists.txt file in:

/root/Desktop/squeak/platforms/unix/npsqueak

I think that is a harmless warning, so you can ignore it.

I'm not so sure. After looking at a few files with that same name in other directories, it might be critical to the overall installation process. I have the impression that it might contain code relating to plug-ins, but I don't know right now which those might be.

It is a harmless warning. Ignore it.

...

Just install it and give it a try. Do "sudo make install", and run /usr/local/bin/squeak yourimage.image

The problem is that as it is, without having run "make install", Squeak crashes and dumps a file.

You are running some random mix of 64 bit executables and 32 bit plugins. This will crash and dump core. Don't do that. As I said before, you just need to install your VM and give it a try.

If you prefer to skip the installation stop, you could manually copy the squeakvm executable and the */so.* modules from your build directory into some target directory and run it from there. If you then put your image and changes and and sources files into the same place, and run the squeakvm executable and the various plugin modules all from the same directory, it should work.

But I strongly advise you *not* to do this. Just install your newly built VM properly and try it. The entire installation will go into /usr/local so you can easily get rid of it if you are not happy with the results.

Summmary: If you install your VM, it will probably work. If you do not install it, it probably won't.

Dave

On Thu, Dec 18, 2014 at 05:46:38AM +0000, B J wrote:

<snip>

...

...

The problem is that as it is, without having run "make install", Squeak crashes and dumps a file.

You are running some random mix of 64 bit executables and 32 bit plugins. This will crash and dump core. Don't do that. As I said before, you just need to install your VM and give it a try.

If you prefer to skip the installation stop, you could manually copy the squeakvm executable and the */so.* modules from your build directory into some target directory and run it from there. If you then put your image and changes and and sources files into the same place, and run the squeakvm executable and the various plugin modules all from the same directory, it should work.

But I strongly advise you *not* to do this. Just install your newly built VM properly and try it. The entire installation will go into /usr/local so you can easily get rid of it if you are not happy with the results.

Summmary: If you install your VM, it will probably work. If you do not install it, it probably won't.

I just tried what you suggested, putting the image on the desktop. Nothing much happens for several minutes, though, when checking using top, I see that it takes a large amount of CPU time. Then it crashes with the only message being "Illegal instruction (core dumped)".

Thanks for trying it.

Darn. I'm sorry it did not work. I'm not really sure what else to suggest at this point :-(

Well, maybe one thing - you might try compiling with gcc optimization turned off. I think that the make file I sent is using "-O3" which is fairly aggressive, you might try setting to "-O0" (zero) and see if it makes a difference.

I've noticed that, during "make", there is an error with Mpeg3Plugin. Even if I disable that during "configure" and proceed with the rest of the installation process, I still get the same crash and error message when I install Squeak and try to run it.

One difference I noticed between when I installed Squeak earlier this year on a different hard drive from the FreeBSD repository and now is that CMake was updated. Back then, it was done using 2.8.x but now it's 3.x and it is fussy about things like CMakeLists.txt files. I'm not quite sure how this exactly affects the building process.

<snip>

I don't think that the CMake version would make any difference.

Sorry, Dave

Wonders never cease. Just for a lark, I successfully installed Squeak on PC-BSD and it ran without a hitch. I guess I made some progress.

I'll still keep tinkering with it on FreeBSD, though. PC-BSD is the complete package and, with FreeBSD, I can customize the installation.

On 18.12.2014, at 05:38, David T. Lewis lewis@mail.msen.com wrote:

On Thu, Dec 18, 2014 at 03:23:31AM +0000, B J wrote:

...

...

...

/root/Desktop/squeak/platforms/unix/npsqueak

I think that is a harmless warning, so you can ignore it.

I'm not so sure.

It is a harmless warning. Ignore it.

Trust David on this one. And his other points too, of course ;)

"npsqueak" is for running Squeak inside a web browser as a plugin ("np" is short for "netscape plugin"). It is not used at all when running Squeak as a stand-alone application.

- Bert -

BJ,

When you get this working, could you please cut-n-paste your top-level CMakeLists.txt and the config.cmake file?

I can then set up a CMakeVMMakerSqueak FreeBSD10.1 configuration so that it generates what you have.

Thanks.

tty