I've been banging my head against building Cog on the primary new Squeak server off and on now for a couple of weeks. This server is 64bit Debian. Note that I don't need and am not trying to build a 64bit VM, a 32bit VM is fine, at least for the time being.
I did of course read unixbuild/HowToBuild and the notes about building on 64bit. Unfortunately that doesn't work, in fact it fails quite early during the configure step (details in a moment). So after looking around a bit I decided that it was all wrong and instead '-m32' should be in CFLAGS. Well that certainly got me a lot farther but then I run into issues linking where gcc is used but without CFLAGS and it goes all pear shaped.
So with my tail between my legs I go back today and try the original suggestion again and to see if I can fix/workaround it. And in fact I'm doing that right now. But then I also decided that I should ask for help, so here I am.
Details:
kencausey@squeak-box4:~/source/cog/svn/Cog/unixbuild/bld$ \ ../../platforms/unix/config/configure CC="gcc -m32" CXX="g++ -m32"\ --without-npsqueak CFLAGS="-g -O2 -msse2 -D_GNU_SOURCE \ -D_FILE^J_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 \ -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" LIBS=-lpthread \
myconf.log 2>&1 &
...
checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details.
excerpt from config.log:
configure:1862: checking for gcc configure:1888: result: gcc -m32 configure:2132: checking for C compiler version configure:2135: gcc -m32 --version </dev/null >&5 gcc (Debian 4.4.5-8) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2138: $? = 0 configure:2140: gcc -m32 -v </dev/null >&5 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) configure:2143: $? = 0 configure:2145: gcc -m32 -V </dev/null >&5 gcc: '-V' must come at the start of the command line configure:2148: $? = 1 configure:2171: checking for C compiler default output file name configure:2174: gcc -m32 -g -O2 -msse2 -D_GNU_SOURCE -D_FILE _OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 conftest.c -lpthread >&5 gcc: _OFFSET_BITS=64: No such file or directory configure:2177: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define SQ_VERSION "4.2-0" | #define VM_VERSION "4.0-2673" | #define OS_TYPE "unix" | #define VM_HOST "x86_64-linux-gnu" | #define VM_HOST_OS "linux-gnu" | #define VM_HOST_CPU "x86_64" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2216: error: C compiler cannot create executables See `config.log' for more details.
Ken
On 26/01/13 20:52, Ken Causey wrote:
I've been banging my head against building Cog on the primary new Squeak server off and on now for a couple of weeks. This server is 64bit Debian. Note that I don't need and am not trying to build a 64bit VM, a 32bit VM is fine, at least for the time being.
I did of course read unixbuild/HowToBuild and the notes about building on 64bit. Unfortunately that doesn't work, in fact it fails quite early during the configure step (details in a moment). So after looking around a bit I decided that it was all wrong and instead '-m32' should be in CFLAGS. Well that certainly got me a lot farther but then I run into issues linking where gcc is used but without CFLAGS and it goes all pear shaped.
So with my tail between my legs I go back today and try the original suggestion again and to see if I can fix/workaround it. And in fact I'm doing that right now. But then I also decided that I should ask for help, so here I am.
Details:
kencausey@squeak-box4:~/source/cog/svn/Cog/unixbuild/bld$ \ ../../platforms/unix/config/configure CC="gcc -m32" CXX="g++ -m32"\ --without-npsqueak CFLAGS="-g -O2 -msse2 -D_GNU_SOURCE \ -D_FILE^J_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 \ -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" LIBS=-lpthread \
myconf.log 2>&1 &
...
checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details.
excerpt from config.log:
configure:1862: checking for gcc configure:1888: result: gcc -m32 configure:2132: checking for C compiler version configure:2135: gcc -m32 --version </dev/null >&5 gcc (Debian 4.4.5-8) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2138: $? = 0 configure:2140: gcc -m32 -v </dev/null >&5 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) configure:2143: $? = 0 configure:2145: gcc -m32 -V </dev/null >&5 gcc: '-V' must come at the start of the command line configure:2148: $? = 1 configure:2171: checking for C compiler default output file name configure:2174: gcc -m32 -g -O2 -msse2 -D_GNU_SOURCE -D_FILE _OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 conftest.c -lpthread >&5 gcc: _OFFSET_BITS=64: No such file or directory configure:2177: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define SQ_VERSION "4.2-0" | #define VM_VERSION "4.0-2673" | #define OS_TYPE "unix" | #define VM_HOST "x86_64-linux-gnu" | #define VM_HOST_OS "linux-gnu" | #define VM_HOST_CPU "x86_64" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2216: error: C compiler cannot create executables See `config.log' for more details.
Ken
Not certain but this bit looks suspect: -D_FILE^J_OFFSET_BITS=64
On 01/26/2013 Derek wrote:
Not certain but this bit looks suspect: -D_FILE^J_OFFSET_BITS=64
*sigh* Yes, and in fact this is far from the first time this cut and paste error has bit me in the last week. Sorry. Ignore this email for now. However I think I will be back because I run into more trouble (but then frankly I may be getting confused now.)
Ken
On 26/01/13 21:16, Ken Causey wrote:
On 01/26/2013 Derek wrote:
Not certain but this bit looks suspect: -D_FILE^J_OFFSET_BITS=64
*sigh* Yes, and in fact this is far from the first time this cut and paste error has bit me in the last week. Sorry. Ignore this email for now. However I think I will be back because I run into more trouble (but then frankly I may be getting confused now.)
Ken
No problem Ken :-) I hit similar problems every time I compile a VM on a new system/os-version and just have to plod my way through.
On 01/26/2013 03:16 PM, Ken Causey wrote:
On 01/26/2013 Derek wrote:
Not certain but this bit looks suspect: -D_FILE^J_OFFSET_BITS=64
*sigh* Yes, and in fact this is far from the first time this cut and paste error has bit me in the last week. Sorry. Ignore this email for now. However I think I will be back because I run into more trouble (but then frankly I may be getting confused now.)
Ken
First let me apologize for the HTML email but this seems to be the only solution when you need to support long lines (with Thunderbird (aka IceDove) which I'm currently using.)
Yes, confused is the word. Sorry about the spurious initial report. As predicted I did run into a problem but I don't remember seeing this one before. First as far as I can tell currently configure runs fine when you don't make a cut and paste error. The problem I'm running into now is with building BochsIA32Plugin:
/bin/bash /home/kencausey/source/cog/svn/Cog/unixbuild/bld/libtool --mode=compile g++ -g -O2 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 -msse -DLSB_FIRST=1 -m32 -DHAVE_CONFIG_H -I/home/kencausey/source/cog/svn/Cog/unixbuild/bld -I/home/kencausey/source/cog/svn/Cog/unixbuild/bld -I/home/kencausey/source/cog/svn/Cog/platforms/unix/vm -I/home/kencausey/source/cog/svn/Cog/platforms/Cross/vm -I/home/kencausey/source/cog/svn/Cog/src/vm -I/home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin -m32 -DUSE_BOCHS_CONFIG_H=1 -I/home/kencausey/source/cog/svn/Cog/processors/IA32/linuxbochs -I/home/kencausey/source/cog/svn/Cog/processors/IA32/bochs -I/home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/instrument/stubs -c -o sqBochsIA32Plugin.lo /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp
g++ -g -O2 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 -msse -DLSB_FIRST=1 -m32 -DHAVE_CONFIG_H -I/home/kencausey/source/cog/svn/Cog/unixbuild/bld -I/home/kencausey/source/cog/svn/Cog/unixbuild/bld -I/home/kencausey/source/cog/svn/Cog/platforms/unix/vm -I/home/kencausey/source/cog/svn/Cog/platforms/Cross/vm -I/home/kencausey/source/cog/svn/Cog/src/vm -I/home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin -m32 -DUSE_BOCHS_CONFIG_H=1 -I/home/kencausey/source/cog/svn/Cog/processors/IA32/linuxbochs -I/home/kencausey/source/cog/svn/Cog/processors/IA32/bochs -I/home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/instrument/stubs -c /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp -fPIC -DPIC -DPIC -o sqBochsIA32Plugin.o In file included from /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:7: /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bochs.h:38:84: error: bochsconfig.h: No such file or directory /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:17:1: warning: "setjmp" redefined In file included from /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:1069, from /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bochs.h:117, from /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:7: /usr/include/setjmp.h:69:1: warning: this is the location of the previous definition /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:282: warning: integer constant is too large for 'long' type /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:286: warning: integer constant is too large for 'long' type In file included from /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bochs.h:113, from /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:7: /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/osdep.h:150: error: 'Bit64u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/osdep.h:165: error: conflicting declaration 'typedef int socklen_t' /usr/include/unistd.h:275: error: 'socklen_t' has a previous declaration as 'typedef __socklen_t socklen_t' In file included from /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bochs.h:114, from /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:7: /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bx_debug/debug.h:34: error: 'Bit32u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bx_debug/debug.h:36: error: 'Bit32u' does not name a type In file included from /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/bochs.h:117, from /home/kencausey/source/cog/svn/Cog/platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp:7: /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:370: error: 'Bit32s' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:396: error: 'Bit32u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:397: error: 'bx_bool' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:407: error: 'Bit16s' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:408: error: 'Bit8u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:474: error: 'Bit8u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:530: error: 'Bit32s' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:580: error: variable 'BOCHSAPI bx_object_c' has initializer but incomplete type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:580: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:581: error: expected primary-expression before 'private' /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:581: error: expected '}' before 'private' /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:581: error: expected ',' or ';' before 'private' /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:584: error: expected unqualified-id before 'protected' /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:586: error: expected unqualified-id before 'public' /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:588: error: expected class-name before '(' token /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:589: error: 'Bit32u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:590: error: 'Bit8u' does not name a type /home/kencausey/source/cog/svn/Cog/processors/IA32/bochs/gui/siminterface.h:591: error: expected declaration before '}' token make[1]: *** [sqBochsIA32Plugin.lo] Error 1 make: *** [BochsIA32Plugin.la] Error 2
I believe the core problem is that it fails to find bochsconfig.h and yet is is in
processors/IA32/linuxbochs/bochsconfig.h
Oops. No.
$ ls -l /home/kencausey/source/cog/svn/Cog/processors/IA32/linuxbochs/ total 4 lrwxrwxrwx 1 kencausey kencausey 8 Jan 23 22:04 bochsconfig.h -> config.h -rwxr-xr-x 1 kencausey kencausey 1436 Jan 23 22:04 conf.COG
bochsconfig.h is a symlink and a dead one at that as there is no config.h in that directory. Just to check I checked out a fresh copy from svn and I see the same in that checkout.
Ken
On 01/26/2013 03:50 PM, Ken Causey wrote:
The problem I'm running into now is with building BochsIA32Plugin:
And a little more careful reading would have indicated that this is because I missed a step. Well, no, I don't really have any need for the Cog VM simulator. So how do I disable building this plugin? Do I need to run VMMaker?
Unless I'm misunderstanding it seems like a mistake to me to have that plugin built by default. But then I guess I am building from development (SVN) sources.
Ken
On 01/26/2013 04:02 PM, Ken Causey wrote:
On 01/26/2013 03:50 PM, Ken Causey wrote:
The problem I'm running into now is with building BochsIA32Plugin:
And a little more careful reading would have indicated that this is because I missed a step. Well, no, I don't really have any need for the Cog VM simulator. So how do I disable building this plugin? Do I need to run VMMaker?
Unless I'm misunderstanding it seems like a mistake to me to have that plugin built by default. But then I guess I am building from development (SVN) sources.
Ken
I'm still hoping there may be something a little simpler than using VMMaker and regenerating the source but while I wait for a response I decided I could at least take a look. First it should be noted that the instructions in HowToBuild are a bit out of date referring to files
http://www.squeakvm.org/svn/squeak/branches/Cog/image/VMMaker-Squeak4.1.chan... http://www.squeakvm.org/svn/squeak/branches/Cog/image/VMMaker-Squeak4.1.imag...
when apparently
CogTrunk43.images and CogTrunk43.changes are apparently the current files in SVN. No?
I ran that and tried VMMaker generateConfiguration but this ran into an MNU for UnixFileDirectory>>pathFromURI: (in VMMaker class>>generateCogVM) which in fact is not defined in this image.
I'm looking into it myself but any available assistance would be appreciated.
Ken
On 01/26/2013 04:31 PM, Ken Causey wrote:
On 01/26/2013 04:02 PM, Ken Causey wrote:
On 01/26/2013 03:50 PM, Ken Causey wrote:
The problem I'm running into now is with building BochsIA32Plugin:
And a little more careful reading would have indicated that this is because I missed a step. Well, no, I don't really have any need for the Cog VM simulator. So how do I disable building this plugin? Do I need to run VMMaker?
Unless I'm misunderstanding it seems like a mistake to me to have that plugin built by default. But then I guess I am building from development (SVN) sources.
Ken
I'm still hoping there may be something a little simpler than using VMMaker and regenerating the source but while I wait for a response I decided I could at least take a look. First it should be noted that the instructions in HowToBuild are a bit out of date referring to files
http://www.squeakvm.org/svn/squeak/branches/Cog/image/VMMaker-Squeak4.1.chan...
http://www.squeakvm.org/svn/squeak/branches/Cog/image/VMMaker-Squeak4.1.imag...
when apparently
CogTrunk43.images and CogTrunk43.changes are apparently the current files in SVN. No?
I ran that and tried VMMaker generateConfiguration but this ran into an MNU for UnixFileDirectory>>pathFromURI: (in VMMaker class>>generateCogVM) which in fact is not defined in this image.
I'm looking into it myself but any available assistance would be appreciated.
Ken
First a correction s/VMMaker class>>generateCogVM/VMMaker class>>generateSqueakCogVM/.
I worked around the pathFromURI: issue by replacing it with fullNameFor: which seems to fit the bill.
But now I'm running into one that's bit more of a challenge for me. In CCodeGenerator>>addMethodFor:selector: there is 'VMClass getVMMaker'. VMClass class>getVMMaker contains a bit of exception system trickery which I'm still trying to grok. But the current symptom is that this returns nil and trying to send #cogitClassName to nil doesn't get very far.
Ken
On Sat, Jan 26, 2013 at 04:02:04PM -0600, Ken Causey wrote:
On 01/26/2013 03:50 PM, Ken Causey wrote:
The problem I'm running into now is with building BochsIA32Plugin:
And a little more careful reading would have indicated that this is because I missed a step. Well, no, I don't really have any need for the Cog VM simulator. So how do I disable building this plugin? Do I need to run VMMaker?
Unless I'm misunderstanding it seems like a mistake to me to have that plugin built by default. But then I guess I am building from development (SVN) sources.
In the Cog build procedure, compiling a plugin is enabled by including the plugin in either the plugins.ext or plugins.int file. These two files should be in your build directory, and the idea is to edit them prior to running configure. To get rid of the that plugin, just find it in one of those two files and edit it out.
If you do want to try running VMMaker, there is a script on the squeakci.org server in the CogVM job that may serve as a useful reference. Look in the workspace for the script file http://squeakci.org/job/CogVM/ws/VMCogUnixBuild.st
You should edit the file and change one line to this before using it, otherwise it will exit your image without saving after you run it:
exitWhenDone := true. "<== EDIT THIS"
That done, you should be able to just file in the script and end up with a Cog VM. Note that the script will write its own plugins.ext and plugins.int files before it does the configure step, so you will probably want to edit that to add the plugins you want.
There is a similar build script for the interpreter VM on squeakci.org also. This uses Ian Piumarta's CMake based build process, which eliminates some of the annoyances you are dealing with here. But that won't help you if you are building a Cog VM, so you'll just need to fiddle with the plugins.ext, plugins.int, and configure parameters until you get what you need. Of course CMake has its own set of annoyances, so pick your poison ;-)
HTH, Dave
On 01/26/2013 04:02 PM, Ken Causey wrote:
On 01/26/2013 03:50 PM, Ken Causey wrote:
The problem I'm running into now is with building BochsIA32Plugin:
And a little more careful reading would have indicated that this is because I missed a step. Well, no, I don't really have any need for the Cog VM simulator. So how do I disable building this plugin? Do I need to run VMMaker?
Unless I'm misunderstanding it seems like a mistake to me to have that plugin built by default. But then I guess I am building from development (SVN) sources.
Ken
David wrote:
In the Cog build procedure, compiling a plugin is enabled by including the plugin in either the plugins.ext or plugins.int file. These two files should be in your build directory, and the idea is to edit them prior to running configure. To get rid of the that plugin, just find it in one of those two files and edit it out.
If you do want to try running VMMaker, there is a script on the squeakci.org server in the CogVM job that may serve as a useful reference. Look in the workspace for the script file http://squeakci.org/job/CogVM/ws/VMCogUnixBuild.st
You should edit the file and change one line to this before using it, otherwise it will exit your image without saving after you run it:
exitWhenDone := true. "<== EDIT THIS"
That done, you should be able to just file in the script and end up with a Cog VM. Note that the script will write its own plugins.ext and plugins.int files before it does the configure step, so you will probably want to edit that to add the plugins you want.
There is a similar build script for the interpreter VM on squeakci.org also. This uses Ian Piumarta's CMake based build process, which eliminates some of the annoyances you are dealing with here. But that won't help you if you are building a Cog VM, so you'll just need to fiddle with the plugins.ext, plugins.int, and configure parameters until you get what you need. Of course CMake has its own set of annoyances, so pick your poison ;-)
HTH, Dave
Thanks Dave! It's been some years since I did more than configure ; make ; make install when building a VM so I've gotten lazy and my memory has faded significantly. I'll stop fighting with the CogVM image for now and try to just modify the plugins files and get on with it. Thanks for the build script, hopefully I won't need it, but now I have it as another reference.
Ken
Thanks to Dave's reminders about plugins.int and plugins.ext I managed to get past the step of building at least an initial Cog VM for testing. But running the tests with a 4.4-12327 image and the built VM resulted in a crash:
Squeak VM version: 4.0-2673 #1 Sun Jan 27 00:56:27 CET 2013 gcc 4.4.5 Built from: CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 27 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 27 2013 Revision: VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cros s/plugins
Build host: Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
C stack backtrace: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/squeak[0x805fc04] /home/kencausey/source/cog/svn/Cog/unixbuild/bld/squeak[0x805fe9f] [0xffffe410] [0xb7255bc9] [0xb722d07e] [0xb722d176] [0xb722d011] [0xb725d9d6] [0xb72e6ad8] [0xb72e6a54] [0xb725535f] [0xb720b2f2] [0xb7209668]
Smalltalk stack dump: 0xffb30850 M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb3086c M BlockClosure>cull: -1200277580: a(n) BlockClosure 0xffb3088c M [] in MethodContext(ContextPart)>handleSignal: -1200277332: a(n) MethodContext 0xffb308ac M BlockClosure>ensure: -1200235732: a(n) BlockClosure 0xffb308cc M MethodContext(ContextPart)>handleSignal: -1200277332: a(n) MethodContext 0xffb308e8 M ProgressNotification(Exception)>signal -1200236048: a(n) ProgressNotification 0xffb30900 M ProgressNotification(Exception)>signal: -1200236048: a(n) ProgressNotification 0xffb30920 M ProgressNotification class>signal:extra: -1215814820: a(n) ProgressNotification class 0xffb3095c M [] in OrderedCollection(Collection)>do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb3097c M OrderedCollection>do: -1200427368: a(n) OrderedCollection 0xffb31fd4 M [] in OrderedCollection(Collection)>do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb31ffc M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb32018 M BlockClosure>on:do: -1200277612: a(n) BlockClosure 0xffb32044 M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb32064 M BlockClosure>ensure: -1200277760: a(n) BlockClosure 0xffb32088 M MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb320b4 M ProgressInitiationException>defaultResumeValue -1200278516: a(n) ProgressInitiationException 0xffb320d0 M ProgressInitiationException(Exception)>resume -1200278516: a(n) ProgressInitiationException 0xffb320e8 M ProgressInitiationException>defaultAction -1200278516: a(n) ProgressInitiationException 0xffb32104 M UndefinedObject>handleSignal: -1221554172: a(n) UndefinedObject 0xffb32120 M ProgressInitiationException(Exception)>signal -1200278516: a(n) ProgressInitiationException 0xffb32138 M ProgressInitiationException>display:at:from:to:during: -1200278516: a(n) ProgressInitiationException 0xffb3216c I ProgressInitiationException class>display:at:from:to:during: -1210997420: a(n) ProgressInitiationException class 0xffb30040 I ByteString(String)>displayProgressAt:from:to:during: -1210991784: a(n) ByteString 0xffb30068 M ByteString(String)>displayProgressFrom:to:during: -1210991784: a(n) ByteString 0xffb30098 M OrderedCollection(Collection)>do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb300d0 I [] in TestRunner>basicRunSuite:do: -1200432232: a(n) TestRunner 0xffb300f0 M BlockClosure>ensure: -1200278860: a(n) BlockClosure 0xffb30114 I TestRunner>basicRunSuite:do: -1200432232: a(n) TestRunner 0xffb3013c I TestRunner>runSuite: -1200432232: a(n) TestRunner 0xffb30160 I TestRunner>runAll -1200432232: a(n) TestRunner 0xffb3017c M SystemReporter>reportTestRunner: -1200872260: a(n) SystemReporter 0xffb31040 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb31060 M OrderedCollection>do: -1200872228: a(n) OrderedCollection 0xffb31080 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb310a0 M TextStream>withAttribute:do: -1200482052: a(n) TextStream 0xffb310c0 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb310e8 I Text class>streamContents: -1216401056: a(n) Text class 0xffb31104 M SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb3111c M SystemReporter>categoryAt:put: -1200872260: a(n) SystemReporter 0xffb31144 I PluggableListMorphOfMany>listSelectionAt:put: -1200866376: a(n) PluggableListMorphOfMany 0xffb3117c I PluggableListMorphOfMany>mouseDown: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f884 M PluggableListMorphOfMany(Morph)>handleMouseDown: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f8a0 M MouseButtonEvent>sentTo: -1200482652: a(n) MouseButtonEvent 0xffb2f8bc M PluggableListMorphOfMany(Morph)>handleEvent: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f8f8 M MorphicEventDispatcher>dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2f918 M MorphicEventDispatcher>dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2f938 M PluggableListMorphOfMany(Morph)>processEvent:using: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f978 M MorphicEventDispatcher>dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e050 M MorphicEventDispatcher>dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e070 M PluggableSystemWindow(Morph)>processEvent:using: -1200870400: a(n) PluggableSystemWindow 0xffb2e0b0 M MorphicEventDispatcher>dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e0d0 M MorphicEventDispatcher>dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e0f0 M PasteUpMorph(Morph)>processEvent:using: -1212910376: a(n) PasteUpMorph 0xffb2e118 M PasteUpMorph>processEvent:using: -1212910376: a(n) PasteUpMorph 0xffb2e138 M PasteUpMorph(Morph)>processEvent: -1212910376: a(n) PasteUpMorph 0xffb2e158 M HandMorph>sendEvent:focus:clear: -1219207060: a(n) HandMorph 0xffb2e17c M HandMorph>sendMouseEvent: -1219207060: a(n) HandMorph 0xffb2e880 M HandMorph>handleEvent: -1219207060: a(n) HandMorph 0xffb2e8ac M HandMorph>processEvents -1219207060: a(n) HandMorph 0xffb2e8c8 M [] in WorldState>doOneCycleNowFor: -1221398640: a(n) WorldState 0xffb2e8ec M Array(SequenceableCollection)>do: -1221482504: a(n) Array 0xffb2e908 M WorldState>handsDo: -1221398640: a(n) WorldState 0xffb2e928 M WorldState>doOneCycleNowFor: -1221398640: a(n) WorldState 0xffb2e944 M WorldState>doOneCycleFor: -1221398640: a(n) WorldState 0xffb2e960 M PasteUpMorph>doOneCycle -1212910376: a(n) PasteUpMorph 0xffb2e980 I [] in Project class>spawnNewProcess -1213766452: a(n) Project class 0xb7d6d640 s [] in BlockClosure>newProcess
Most recent primitives perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ species species @ at:put: basicNew new: species basicNew new: species basicNew new: at:put: wait signal primShowRectLeft:right:top:bottom: primitiveDeferUpdates: forceDisplayUpdate findNextUnwindContextUpTo: tempAt: tempAt:put: tempAt: terminateTo: tempAt:put: findNextUnwindContextUpTo: terminateTo: millisecondClockValue value: instVarsInclude: instVarsInclude: objectAt: objectAt: basicNew basicNew objectAt: basicNew: stackp: basicNew primitiveResume wait signal millisecondClockValue at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew basicNew new: at:put: at:put: at:put: signal findNextUnwindContextUpTo: terminateTo: suspend instVarsInclude: instVarsInclude: objectAt: objectAt: basicNew basicNew objectAt: basicNew: stackp: basicNew primitiveResume wait signal millisecondClockValue at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew basicNew new: at:put: at:put: at:put: perform: on:do: value new: at:put: new: at:put: basicNew basicNew wait wait signal wait signal wait signal signal wait basicNew: replaceFrom:to:with:startingAt: new: at:put: species new: replaceFrom:to:with:startingAt: basicNew basicNew stringHash:initialHash: compare:with:collated: stringHash:initialHash: basicNew signal findNextUnwindContextUpTo: terminateTo: suspend at:put: primSecondsClock digitCompare: millisecondClockValue basicAt: basicAt: bitShiftMagnitude: basicAt: perform:with:
=
basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: bitShiftMagnitude: perform:with: <= perform:with: - truncated value: basicNew: basicNew basicNew: basicNew at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: compare:with:collated: basicNew findNextHandlerContextStarting tempAt: tempAt: tempAt:put: tempAt:
(Segmentation fault) Aborted
See bottom for SqueakDebug.log contents which I should have included originally.
On 01/26/2013 06:13 PM, Ken Causey wrote:
Thanks to Dave's reminders about plugins.int and plugins.ext I managed to get past the step of building at least an initial Cog VM for testing. But running the tests with a 4.4-12327 image and the built VM resulted in a crash:
Squeak VM version: 4.0-2673 #1 Sun Jan 27 00:56:27 CET 2013 gcc 4.4.5 Built from: CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 27 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 27 2013 Revision: VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cros s/plugins Build host: Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
C stack backtrace: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/squeak[0x805fc04] /home/kencausey/source/cog/svn/Cog/unixbuild/bld/squeak[0x805fe9f] [0xffffe410] [0xb7255bc9] [0xb722d07e] [0xb722d176] [0xb722d011] [0xb725d9d6] [0xb72e6ad8] [0xb72e6a54] [0xb725535f] [0xb720b2f2] [0xb7209668]
Smalltalk stack dump: 0xffb30850 M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb3086c M BlockClosure>cull: -1200277580: a(n) BlockClosure 0xffb3088c M [] in MethodContext(ContextPart)>handleSignal: -1200277332: a(n) MethodContext 0xffb308ac M BlockClosure>ensure: -1200235732: a(n) BlockClosure 0xffb308cc M MethodContext(ContextPart)>handleSignal: -1200277332: a(n) MethodContext 0xffb308e8 M ProgressNotification(Exception)>signal -1200236048: a(n) ProgressNotification 0xffb30900 M ProgressNotification(Exception)>signal: -1200236048: a(n) ProgressNotification 0xffb30920 M ProgressNotification class>signal:extra: -1215814820: a(n) ProgressNotification class 0xffb3095c M [] in OrderedCollection(Collection)>do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb3097c M OrderedCollection>do: -1200427368: a(n) OrderedCollection 0xffb31fd4 M [] in OrderedCollection(Collection)>do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb31ffc M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb32018 M BlockClosure>on:do: -1200277612: a(n) BlockClosure 0xffb32044 M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb32064 M BlockClosure>ensure: -1200277760: a(n) BlockClosure 0xffb32088 M MorphicUIManager>displayProgress:at:from:to:during: -1211236388: a(n) MorphicUIManager 0xffb320b4 M ProgressInitiationException>defaultResumeValue -1200278516: a(n) ProgressInitiationException 0xffb320d0 M ProgressInitiationException(Exception)>resume -1200278516: a(n) ProgressInitiationException 0xffb320e8 M ProgressInitiationException>defaultAction -1200278516: a(n) ProgressInitiationException 0xffb32104 M UndefinedObject>handleSignal: -1221554172: a(n) UndefinedObject 0xffb32120 M ProgressInitiationException(Exception)>signal -1200278516: a(n) ProgressInitiationException 0xffb32138 M ProgressInitiationException>display:at:from:to:during: -1200278516: a(n) ProgressInitiationException 0xffb3216c I ProgressInitiationException class>display:at:from:to:during: -1210997420: a(n) ProgressInitiationException class 0xffb30040 I ByteString(String)>displayProgressAt:from:to:during: -1210991784: a(n) ByteString 0xffb30068 M ByteString(String)>displayProgressFrom:to:during: -1210991784: a(n) ByteString 0xffb30098 M OrderedCollection(Collection)>do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb300d0 I [] in TestRunner>basicRunSuite:do: -1200432232: a(n) TestRunner 0xffb300f0 M BlockClosure>ensure: -1200278860: a(n) BlockClosure 0xffb30114 I TestRunner>basicRunSuite:do: -1200432232: a(n) TestRunner 0xffb3013c I TestRunner>runSuite: -1200432232: a(n) TestRunner 0xffb30160 I TestRunner>runAll -1200432232: a(n) TestRunner 0xffb3017c M SystemReporter>reportTestRunner: -1200872260: a(n) SystemReporter 0xffb31040 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb31060 M OrderedCollection>do: -1200872228: a(n) OrderedCollection 0xffb31080 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb310a0 M TextStream>withAttribute:do: -1200482052: a(n) TextStream 0xffb310c0 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb310e8 I Text class>streamContents: -1216401056: a(n) Text class 0xffb31104 M SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb3111c M SystemReporter>categoryAt:put: -1200872260: a(n) SystemReporter 0xffb31144 I PluggableListMorphOfMany>listSelectionAt:put: -1200866376: a(n) PluggableListMorphOfMany 0xffb3117c I PluggableListMorphOfMany>mouseDown: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f884 M PluggableListMorphOfMany(Morph)>handleMouseDown: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f8a0 M MouseButtonEvent>sentTo: -1200482652: a(n) MouseButtonEvent 0xffb2f8bc M PluggableListMorphOfMany(Morph)>handleEvent: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f8f8 M MorphicEventDispatcher>dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2f918 M MorphicEventDispatcher>dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2f938 M PluggableListMorphOfMany(Morph)>processEvent:using: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f978 M MorphicEventDispatcher>dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e050 M MorphicEventDispatcher>dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e070 M PluggableSystemWindow(Morph)>processEvent:using: -1200870400: a(n) PluggableSystemWindow 0xffb2e0b0 M MorphicEventDispatcher>dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e0d0 M MorphicEventDispatcher>dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e0f0 M PasteUpMorph(Morph)>processEvent:using: -1212910376: a(n) PasteUpMorph 0xffb2e118 M PasteUpMorph>processEvent:using: -1212910376: a(n) PasteUpMorph 0xffb2e138 M PasteUpMorph(Morph)>processEvent: -1212910376: a(n) PasteUpMorph 0xffb2e158 M HandMorph>sendEvent:focus:clear: -1219207060: a(n) HandMorph 0xffb2e17c M HandMorph>sendMouseEvent: -1219207060: a(n) HandMorph 0xffb2e880 M HandMorph>handleEvent: -1219207060: a(n) HandMorph 0xffb2e8ac M HandMorph>processEvents -1219207060: a(n) HandMorph 0xffb2e8c8 M [] in WorldState>doOneCycleNowFor: -1221398640: a(n) WorldState 0xffb2e8ec M Array(SequenceableCollection)>do: -1221482504: a(n) Array 0xffb2e908 M WorldState>handsDo: -1221398640: a(n) WorldState 0xffb2e928 M WorldState>doOneCycleNowFor: -1221398640: a(n) WorldState 0xffb2e944 M WorldState>doOneCycleFor: -1221398640: a(n) WorldState 0xffb2e960 M PasteUpMorph>doOneCycle -1212910376: a(n) PasteUpMorph 0xffb2e980 I [] in Project class>spawnNewProcess -1213766452: a(n) Project class 0xb7d6d640 s [] in BlockClosure>newProcess
Most recent primitives perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew @ @ primDisplayString:from:to:map:xTable:kern: @ primDisplayString:from:to:map:xTable:kern: @ species species @ at:put: basicNew new: species basicNew new: species basicNew new: at:put: wait signal primShowRectLeft:right:top:bottom: primitiveDeferUpdates: forceDisplayUpdate findNextUnwindContextUpTo: tempAt: tempAt:put: tempAt: terminateTo: tempAt:put: findNextUnwindContextUpTo: terminateTo: millisecondClockValue value: instVarsInclude: instVarsInclude: objectAt: objectAt: basicNew basicNew objectAt: basicNew: stackp: basicNew primitiveResume wait signal millisecondClockValue at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew basicNew new: at:put: at:put: at:put: signal findNextUnwindContextUpTo: terminateTo: suspend instVarsInclude: instVarsInclude: objectAt: objectAt: basicNew basicNew objectAt: basicNew: stackp: basicNew primitiveResume wait signal millisecondClockValue at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew basicNew new: at:put: at:put: at:put: perform: on:do: value new: at:put: new: at:put: basicNew basicNew wait wait signal wait signal wait signal signal wait basicNew: replaceFrom:to:with:startingAt: new: at:put: species new: replaceFrom:to:with:startingAt: basicNew basicNew stringHash:initialHash: compare:with:collated: stringHash:initialHash: basicNew signal findNextUnwindContextUpTo: terminateTo: suspend at:put: primSecondsClock digitCompare: millisecondClockValue basicAt: basicAt: bitShiftMagnitude: basicAt: perform:with:
=
basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt:
bitOr: bitShiftMagnitude: perform:with: <= perform:with:
truncated value: basicNew: basicNew basicNew: basicNew at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: compare:with:collated: basicNew findNextHandlerContextStarting tempAt: tempAt: tempAt:put: tempAt:
(Segmentation fault) Aborted
SqueakDebug.log:
TestFailure: Assertion failed 8 January 2013 12:55:42.928 am
VM: unix - Smalltalk Image: Squeak4.4 [latest update: #12327]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/kencausey/testing Trusted Dir /home/kencausey/testing/secure Untrusted Dir /home/kencausey/testing/My Squeak
LocaleTest(TestCase)>>signalFailure: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: aString: 'Assertion failed' Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
LocaleTest(TestCase)>>assert: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: aBooleanOrBlock: false Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
LocaleTest>>testLocaleChanged Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
LocaleTest(TestCase)>>performTest Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
[] in [] in LocaleTest(TestCase)>>runCase Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
BlockClosure>>on:do: Receiver: [closure] in [] in LocaleTest(TestCase)>>runCase Arguments and temporary variables: exception: an ExceptionSet handlerAction: [closure] in [] in LocaleTest(TestCase)>>timeout:after: handlerActive: false Receiver's instance variables: outerContext: [] in LocaleTest(TestCase)>>runCase startpc: 62 numArgs: 0
[] in LocaleTest(TestCase)>>timeout:after: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: <<error during printing> Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
BlockClosure>>ensure: Receiver: [closure] in LocaleTest(TestCase)>>timeout:after: Arguments and temporary variables: aBlock: [closure] in LocaleTest(TestCase)>>timeout:after: complete: nil returnValue: nil Receiver's instance variables: outerContext: LocaleTest(TestCase)>>timeout:after: startpc: 153 numArgs: 0
LocaleTest(TestCase)>>timeout:after: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: aBlock: [closure] in [] in LocaleTest(TestCase)>>runCase seconds: 60 delay: a Delay(60000 msecs; 59622 msecs remaining) watchdog: a Process in [] in Delay>>wait theProcess: #(nil) Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
[] in LocaleTest(TestCase)>>runCase Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
BlockClosure>>ensure: Receiver: [closure] in LocaleTest(TestCase)>>runCase Arguments and temporary variables: aBlock: [closure] in LocaleTest(TestCase)>>runCase complete: nil returnValue: nil Receiver's instance variables: outerContext: LocaleTest(TestCase)>>runCase startpc: 45 numArgs: 0
LocaleTest(TestCase)>>runCase Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
[] in LocaleTest(TestCase)>>debug Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
BlockClosure>>ensure: Receiver: [closure] in LocaleTest(TestCase)>>debug Arguments and temporary variables: aBlock: [closure] in LocaleTest(TestCase)>>debug complete: nil returnValue: nil Receiver's instance variables: outerContext: LocaleTest(TestCase)>>debug startpc: 62 numArgs: 0
LocaleTest(TestCase)>>debug Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
[] in TestRunner>>debugSuite: Receiver: a TestRunner Arguments and temporary variables: <<error during printing> Receiver's instance variables: categories: #(#'KernelTests-Chronology' #'KernelTests-Classes' #'KernelTests-Me...etc... categoriesSelected: a Set(#'Universes-Tests' #'Tests-PrimCallController' #'Test...etc... classes: {TestCase . AllocationTest . ArbitraryObjectSocketTestCase . ArrayLite...etc... classIndex: 0 classesSelected: a Set(WeakMessageSendTest MCAncestryTest SemaphoreTest Depende...etc... failedList: {LocaleTest>>#testLocaleChanged . ReleaseTest>>#testNoObsoleteClass...etc... failedSelected: LocaleTest>>#testLocaleChanged errorList: #() errorSelected: nil lastUpdate: 3535058965 result: 3272 run, 3252 passes, 18 expected failures, 2 failures, 0 errors, 0 un...etc... previousRun: nil categoryPattern: nil classPattern: nil
[] in [] in OrderedCollection(Collection)>>do:displayingProgress:every: Receiver: an OrderedCollection(LocaleTest>>#testLocaleChanged) Arguments and temporary variables: <<error during printing> Receiver's instance variables: array: {LocaleTest>>#testLocaleChanged . nil . nil . nil . nil . nil . nil . ni...etc... firstIndex: 1 lastIndex: 1
OrderedCollection>>do: Receiver: an OrderedCollection(LocaleTest>>#testLocaleChanged) Arguments and temporary variables: aBlock: [closure] in [] in OrderedCollection(Collection)>>do:displayingProgress...etc... index: 1 Receiver's instance variables: array: {LocaleTest>>#testLocaleChanged . nil . nil . nil . nil . nil . nil . ni...etc... firstIndex: 1 lastIndex: 1
[] in OrderedCollection(Collection)>>do:displayingProgress:every: Receiver: an OrderedCollection(LocaleTest>>#testLocaleChanged) Arguments and temporary variables: <<error during printing> Receiver's instance variables: array: {LocaleTest>>#testLocaleChanged . nil . nil . nil . nil . nil . nil . ni...etc... firstIndex: 1 lastIndex: 1
--- The full stack --- LocaleTest(TestCase)>>signalFailure: LocaleTest(TestCase)>>assert: LocaleTest>>testLocaleChanged LocaleTest(TestCase)>>performTest [] in [] in LocaleTest(TestCase)>>runCase BlockClosure>>on:do: [] in LocaleTest(TestCase)>>timeout:after: BlockClosure>>ensure: LocaleTest(TestCase)>>timeout:after: [] in LocaleTest(TestCase)>>runCase BlockClosure>>ensure: LocaleTest(TestCase)>>runCase [] in LocaleTest(TestCase)>>debug BlockClosure>>ensure: LocaleTest(TestCase)>>debug [] in TestRunner>>debugSuite: [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every: OrderedCollection>>do: [] in OrderedCollection(Collection)>>do:displayingProgress:every: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [] in [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>on:do: [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>ensure: MorphicUIManager>>displayProgress:at:from:to:during: ProgressInitiationException>>defaultResumeValue ProgressInitiationException(Exception)>>resume ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: ByteString(String)>>displayProgressFrom:to:during: OrderedCollection(Collection)>>do:displayingProgress:every: [] in TestRunner>>basicRunSuite:do: BlockClosure>>ensure: TestRunner>>basicRunSuite:do: TestRunner>>debugSuite: TestRunner>>debug: TestRunner>>failedSelected: PluggableListMorphPlus(PluggableListMorph)>>changeModelSelection: PluggableListMorphPlus(PluggableListMorph)>>mouseUp: PluggableListMorphPlus(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableListMorphPlus(Morph)>>handleEvent: PluggableListMorphPlus(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle -- and more not shown --
Hi Ken,
yes, I introduced a regression with the latest check-in that I'll fix soon. For the moment use version 2672 of the sources. To stop the Bochs plugin being built edit unixbuild/bld/plugins.ext and delete it from there. It being built by default is entirely for my benefit. Apologies.
On Sat, Jan 26, 2013 at 4:17 PM, Ken Causey ken@kencausey.com wrote:
See bottom for SqueakDebug.log contents which I should have included originally.
On 01/26/2013 06:13 PM, Ken Causey wrote:
Thanks to Dave's reminders about plugins.int and plugins.ext I managed to get past the step of building at least an initial Cog VM for testing. But running the tests with a 4.4-12327 image and the built VM resulted in a crash:
Squeak VM version: 4.0-2673 #1 Sun Jan 27 00:56:27 CET 2013 gcc 4.4.5 Built from: CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-**f462b300a2ea Jan 27 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-**cf4f58ee5d64 Jan 27 2013 Revision: VM: r2673 http://www.squeakvm.org/svn/**squeak/branches/Coghttp://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/**squeak/trunk/platforms/Croshttp://squeakvm.org/svn/squeak/trunk/platforms/Cros s/plugins Build host: Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/]
C stack backtrace: /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/squeak[**0x805fc04] /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/squeak[**0x805fe9f] [0xffffe410] [0xb7255bc9] [0xb722d07e] [0xb722d176] [0xb722d011] [0xb725d9d6] [0xb72e6ad8] [0xb72e6a54] [0xb725535f] [0xb720b2f2] [0xb7209668]
Smalltalk stack dump: 0xffb30850 M [] in MorphicUIManager>**displayProgress:at:from:to:** during: -1211236388: a(n) MorphicUIManager 0xffb3086c M BlockClosure>cull: -1200277580: a(n) BlockClosure 0xffb3088c M [] in MethodContext(ContextPart)>**handleSignal: -1200277332: a(n) MethodContext 0xffb308ac M BlockClosure>ensure: -1200235732: a(n) BlockClosure 0xffb308cc M MethodContext(ContextPart)>**handleSignal: -1200277332: a(n) MethodContext 0xffb308e8 M ProgressNotification(**Exception)>signal -1200236048: a(n) ProgressNotification 0xffb30900 M ProgressNotification(**Exception)>signal: -1200236048: a(n) ProgressNotification 0xffb30920 M ProgressNotification class>signal:extra: -1215814820: a(n) ProgressNotification class 0xffb3095c M [] in OrderedCollection(Collection)>**do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb3097c M OrderedCollection>do: -1200427368: a(n) OrderedCollection 0xffb31fd4 M [] in OrderedCollection(Collection)>**do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb31ffc M [] in MorphicUIManager>**displayProgress:at:from:to:** during: -1211236388: a(n) MorphicUIManager 0xffb32018 M BlockClosure>on:do: -1200277612: a(n) BlockClosure 0xffb32044 M [] in MorphicUIManager>**displayProgress:at:from:to:** during: -1211236388: a(n) MorphicUIManager 0xffb32064 M BlockClosure>ensure: -1200277760: a(n) BlockClosure 0xffb32088 M MorphicUIManager>**displayProgress:at:from:to:**during: -1211236388: a(n) MorphicUIManager 0xffb320b4 M ProgressInitiationException>**defaultResumeValue -1200278516: a(n) ProgressInitiationException 0xffb320d0 M ProgressInitiationException(**Exception)>resume -1200278516: a(n) ProgressInitiationException 0xffb320e8 M ProgressInitiationException>**defaultAction -1200278516: a(n) ProgressInitiationException 0xffb32104 M UndefinedObject>handleSignal: -1221554172: a(n) UndefinedObject 0xffb32120 M ProgressInitiationException(**Exception)>signal -1200278516: a(n) ProgressInitiationException 0xffb32138 M ProgressInitiationException>**display:at:from:to:during: -1200278516: a(n) ProgressInitiationException 0xffb3216c I ProgressInitiationException class>display:at:from:to:**during: -1210997420: a(n) ProgressInitiationException class 0xffb30040 I ByteString(String)>**displayProgressAt:from:to:**during: -1210991784: a(n) ByteString 0xffb30068 M ByteString(String)>**displayProgressFrom:to:during: -1210991784: a(n) ByteString 0xffb30098 M OrderedCollection(Collection)>**do:displayingProgress:every: -1200427368: a(n) OrderedCollection 0xffb300d0 I [] in TestRunner>basicRunSuite:do: -1200432232: a(n) TestRunner 0xffb300f0 M BlockClosure>ensure: -1200278860: a(n) BlockClosure 0xffb30114 I TestRunner>basicRunSuite:do: -1200432232: a(n) TestRunner 0xffb3013c I TestRunner>runSuite: -1200432232: a(n) TestRunner 0xffb30160 I TestRunner>runAll -1200432232: a(n) TestRunner 0xffb3017c M SystemReporter>**reportTestRunner: -1200872260: a(n) SystemReporter 0xffb31040 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb31060 M OrderedCollection>do: -1200872228: a(n) OrderedCollection 0xffb31080 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb310a0 M TextStream>withAttribute:do: -1200482052: a(n) TextStream 0xffb310c0 M [] in SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb310e8 I Text class>streamContents: -1216401056: a(n) Text class 0xffb31104 M SystemReporter>updateReport -1200872260: a(n) SystemReporter 0xffb3111c M SystemReporter>categoryAt:put: -1200872260: a(n) SystemReporter 0xffb31144 I PluggableListMorphOfMany>**listSelectionAt:put: -1200866376: a(n) PluggableListMorphOfMany 0xffb3117c I PluggableListMorphOfMany>**mouseDown: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f884 M PluggableListMorphOfMany(**Morph)>handleMouseDown: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f8a0 M MouseButtonEvent>sentTo: -1200482652: a(n) MouseButtonEvent 0xffb2f8bc M PluggableListMorphOfMany(**Morph)>handleEvent: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f8f8 M MorphicEventDispatcher>**dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2f918 M MorphicEventDispatcher>**dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2f938 M PluggableListMorphOfMany(**Morph)>processEvent:using: -1200866376: a(n) PluggableListMorphOfMany 0xffb2f978 M MorphicEventDispatcher>**dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e050 M MorphicEventDispatcher>**dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e070 M PluggableSystemWindow(Morph)>**processEvent:using: -1200870400: a(n) PluggableSystemWindow 0xffb2e0b0 M MorphicEventDispatcher>**dispatchMouseDown:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e0d0 M MorphicEventDispatcher>**dispatchEvent:with: -1200482800: a(n) MorphicEventDispatcher 0xffb2e0f0 M PasteUpMorph(Morph)>**processEvent:using: -1212910376: a(n) PasteUpMorph 0xffb2e118 M PasteUpMorph>processEvent:**using: -1212910376: a(n) PasteUpMorph 0xffb2e138 M PasteUpMorph(Morph)>**processEvent: -1212910376: a(n) PasteUpMorph 0xffb2e158 M HandMorph>sendEvent:focus:**clear: -1219207060: a(n) HandMorph 0xffb2e17c M HandMorph>sendMouseEvent: -1219207060: a(n) HandMorph 0xffb2e880 M HandMorph>handleEvent: -1219207060: a(n) HandMorph 0xffb2e8ac M HandMorph>processEvents -1219207060: a(n) HandMorph 0xffb2e8c8 M [] in WorldState>doOneCycleNowFor: -1221398640: a(n) WorldState 0xffb2e8ec M Array(SequenceableCollection)>**do: -1221482504: a(n) Array 0xffb2e908 M WorldState>handsDo: -1221398640: a(n) WorldState 0xffb2e928 M WorldState>doOneCycleNowFor: -1221398640: a(n) WorldState 0xffb2e944 M WorldState>doOneCycleFor: -1221398640: a(n) WorldState 0xffb2e960 M PasteUpMorph>doOneCycle -1212910376: a(n) PasteUpMorph 0xffb2e980 I [] in Project class>spawnNewProcess -1213766452: a(n) Project class 0xb7d6d640 s [] in BlockClosure>newProcess
Most recent primitives perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew @ @ @ basicNew @ perform:with: @ @ perform:with: @ basicNew copyBits @ @ basicNew @ @ primDisplayString:from:to:map:**xTable:kern: @ primDisplayString:from:to:map:**xTable:kern: @ species species @ at:put: basicNew new: species basicNew new: species basicNew new: at:put: wait signal primShowRectLeft:right:top:**bottom: primitiveDeferUpdates: forceDisplayUpdate findNextUnwindContextUpTo: tempAt: tempAt:put: tempAt: terminateTo: tempAt:put: findNextUnwindContextUpTo: terminateTo: millisecondClockValue value: instVarsInclude: instVarsInclude: objectAt: objectAt: basicNew basicNew objectAt: basicNew: stackp: basicNew primitiveResume wait signal millisecondClockValue at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew basicNew new: at:put: at:put: at:put: signal findNextUnwindContextUpTo: terminateTo: suspend instVarsInclude: instVarsInclude: objectAt: objectAt: basicNew basicNew objectAt: basicNew: stackp: basicNew primitiveResume wait signal millisecondClockValue at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait basicNew basicNew new: at:put: at:put: at:put: perform: on:do: value new: at:put: new: at:put: basicNew basicNew wait wait signal wait signal wait signal signal wait basicNew: replaceFrom:to:with:**startingAt: new: at:put: species new: replaceFrom:to:with:**startingAt: basicNew basicNew stringHash:initialHash: compare:with:collated: stringHash:initialHash: basicNew signal findNextUnwindContextUpTo: terminateTo: suspend at:put: primSecondsClock digitCompare: millisecondClockValue basicAt: basicAt: bitShiftMagnitude: basicAt: perform:with:
=
basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt:
bitOr: bitShiftMagnitude: perform:with: <= perform:with:
truncated value: basicNew: basicNew basicNew: basicNew at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species basicNew: replaceFrom:to:with:**startingAt: replaceFrom:to:with:**startingAt: replaceFrom:to:with:**startingAt: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species basicNew: replaceFrom:to:with:**startingAt: species basicNew: replaceFrom:to:with:**startingAt: replaceFrom:to:with:**startingAt: compare:with:collated: basicNew findNextHandlerContextStarting tempAt: tempAt: tempAt:put: tempAt:
(Segmentation fault) Aborted
SqueakDebug.log:
TestFailure: Assertion failed 8 January 2013 12:55:42.928 am
VM: unix - Smalltalk Image: Squeak4.4 [latest update: #12327]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/kencausey/testing Trusted Dir /home/kencausey/testing/secure Untrusted Dir /home/kencausey/testing/My Squeak
LocaleTest(TestCase)>>**signalFailure: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: aString: 'Assertion failed' Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
LocaleTest(TestCase)>>assert: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: aBooleanOrBlock: false Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
LocaleTest>>testLocaleChanged Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nilLocaleTest(TestCase)>>**performTest Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil[] in [] in LocaleTest(TestCase)>>runCase Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nilBlockClosure>>on:do: Receiver: [closure] in [] in LocaleTest(TestCase)>>runCase Arguments and temporary variables: exception: an ExceptionSet handlerAction: [closure] in [] in LocaleTest(TestCase)>>timeout:**after: handlerActive: false Receiver's instance variables: outerContext: [] in LocaleTest(TestCase)>>runCase startpc: 62 numArgs: 0
[] in LocaleTest(TestCase)>>timeout:**after: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: <<error during printing> Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
BlockClosure>>ensure: Receiver: [closure] in LocaleTest(TestCase)>>timeout:**after: Arguments and temporary variables: aBlock: [closure] in LocaleTest(TestCase)>>timeout: **after: complete: nil returnValue: nil Receiver's instance variables: outerContext: LocaleTest(TestCase)>>timeout:**after: startpc: 153 numArgs: 0
LocaleTest(TestCase)>>timeout:**after: Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables: aBlock: [closure] in [] in LocaleTest(TestCase)>>runCase seconds: 60 delay: a Delay(60000 msecs; 59622 msecs remaining) watchdog: a Process in [] in Delay>>wait theProcess: #(nil) Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil
[] in LocaleTest(TestCase)>>runCase Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nilBlockClosure>>ensure: Receiver: [closure] in LocaleTest(TestCase)>>runCase Arguments and temporary variables: aBlock: [closure] in LocaleTest(TestCase)>>runCase complete: nil returnValue: nil Receiver's instance variables: outerContext: LocaleTest(TestCase)>>runCase startpc: 45 numArgs: 0
LocaleTest(TestCase)>>runCase Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil[] in LocaleTest(TestCase)>>debug Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nilBlockClosure>>ensure: Receiver: [closure] in LocaleTest(TestCase)>>debug Arguments and temporary variables: aBlock: [closure] in LocaleTest(TestCase)>>debug complete: nil returnValue: nil Receiver's instance variables: outerContext: LocaleTest(TestCase)>>debug startpc: 62 numArgs: 0
LocaleTest(TestCase)>>debug Receiver: LocaleTest>>#testLocaleChanged Arguments and temporary variables:
Receiver's instance variables: testSelector: #testLocaleChanged timeout: nil[] in TestRunner>>debugSuite: Receiver: a TestRunner Arguments and temporary variables: <<error during printing> Receiver's instance variables: categories: #(#'KernelTests-Chronology' #'KernelTests-Classes' #'KernelTests-Me...etc... categoriesSelected: a Set(#'Universes-Tests' #'Tests-PrimCallController' #'Test...etc... classes: {TestCase . AllocationTest . ArbitraryObjectSocketTestCase . ArrayLite...etc... classIndex: 0 classesSelected: a Set(WeakMessageSendTest MCAncestryTest SemaphoreTest Depende...etc... failedList: {LocaleTest>>#**testLocaleChanged . ReleaseTest>>#**testNoObsoleteClass...etc... failedSelected: LocaleTest>>#testLocaleChanged errorList: #() errorSelected: nil lastUpdate: 3535058965 result: 3272 run, 3252 passes, 18 expected failures, 2 failures, 0 errors, 0 un...etc... previousRun: nil categoryPattern: nil classPattern: nil
[] in [] in OrderedCollection(Collection)>**>do:displayingProgress:every: Receiver: an OrderedCollection(LocaleTest>>**#testLocaleChanged) Arguments and temporary variables: <<error during printing> Receiver's instance variables: array: {LocaleTest>>#**testLocaleChanged . nil . nil . nil . nil . nil . nil . ni...etc... firstIndex: 1 lastIndex: 1
OrderedCollection>>do: Receiver: an OrderedCollection(LocaleTest>>**#testLocaleChanged) Arguments and temporary variables: aBlock: [closure] in [] in OrderedCollection(Collection)>**>do:displayingProgress...etc..**. index: 1 Receiver's instance variables: array: {LocaleTest>>#**testLocaleChanged . nil . nil . nil . nil . nil . nil . ni...etc... firstIndex: 1 lastIndex: 1
[] in OrderedCollection(Collection)>**>do:displayingProgress:every: Receiver: an OrderedCollection(LocaleTest>>**#testLocaleChanged) Arguments and temporary variables: <<error during printing> Receiver's instance variables: array: {LocaleTest>>#**testLocaleChanged . nil . nil . nil . nil . nil . nil . ni...etc... firstIndex: 1 lastIndex: 1
--- The full stack --- LocaleTest(TestCase)>>**signalFailure: LocaleTest(TestCase)>>assert: LocaleTest>>testLocaleChanged LocaleTest(TestCase)>>**performTest [] in [] in LocaleTest(TestCase)>>runCase BlockClosure>>on:do: [] in LocaleTest(TestCase)>>timeout:**after: BlockClosure>>ensure: LocaleTest(TestCase)>>timeout:**after: [] in LocaleTest(TestCase)>>runCase BlockClosure>>ensure: LocaleTest(TestCase)>>runCase [] in LocaleTest(TestCase)>>debug BlockClosure>>ensure: LocaleTest(TestCase)>>debug [] in TestRunner>>debugSuite: [] in [] in OrderedCollection(Collection)>**>do:displayingProgress:every: OrderedCollection>>do:
[] in OrderedCollection(Collection)>**>do:displayingProgress:every:
[] in [] in MorphicUIManager>>**displayProgress:at:from:to:**during: BlockClosure>>on:do:
[] in MorphicUIManager>>**displayProgress:at:from:to:**during: BlockClosure>>ensure:
MorphicUIManager>>**displayProgress:at:from:to:**during: ProgressInitiationException>>**defaultResumeValue ProgressInitiationException(**Exception)>>resume ProgressInitiationException>>**defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>**handleSignal: ProgressInitiationException(**Exception)>>signal
ProgressInitiationException>>**display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:**during: ByteString(String)>>**displayProgressAt:from:to:**during: ByteString(String)>>**displayProgressFrom:to:during: OrderedCollection(Collection)>**>do:displayingProgress:every: [] in TestRunner>>basicRunSuite:do: BlockClosure>>ensure: TestRunner>>basicRunSuite:do: TestRunner>>debugSuite: TestRunner>>debug: TestRunner>>failedSelected: PluggableListMorphPlus(**PluggableListMorph)>>**changeModelSelection: PluggableListMorphPlus(**PluggableListMorph)>>mouseUp: PluggableListMorphPlus(Morph)>**>handleMouseUp: MouseButtonEvent>>sentTo: PluggableListMorphPlus(Morph)>**>handleEvent: PluggableListMorphPlus(Morph)>**>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:**clear: BlockClosure>>on:do: PasteUpMorph>>**becomeActiveDuring: HandMorph>>sendFocusEvent:to:**clear: HandMorph>>sendEvent:focus:**clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>**>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle -- and more not shown --
Eliot said:
Hi Ken,
yes, I introduced a regression with the latest check-in that I'll fixsoon. For the moment use version 2672 of the sources. To stop the Bochs plugin being built edit unixbuild/bld/plugins.ext and delete it from there. It being built by default is entirely for my benefit. Apologies.
Thanks Eliot. Unfortunately that doesn't seem to have helped. I deleted my checkout entirely and then
$ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/@2672
And built that (after one failure because I forgot to edit plugins.ext). I haven't analyzed it in detail but it seems be the same issue I had before
Squeak VM version: 4.0-2672 #1 Mon Jan 28 21:08:17 CET 2013 gcc 4.4.5 Built from: CoInterpreter VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Jan 28 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Jan 28 2013 Revision: VM: r2672 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Build host: Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
C stack backtrace: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/squeak[0x805fb94] /home/kencausey/source/cog/svn/Cog/unixbuild/bld/squeak[0x805fe2f] [0xffffe410] [0xb71c97c8]
...
Smalltalk stack dump: 0xffb3ba50 M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211499496: a(n) MorphicUIManager 0xffb3ba74 I BlockClosure>cull: -1202719336: a(n) BlockClosure 0xffb3ba94 M [] in MethodContext(ContextPart)>handleSignal: -1202719088: a(n) MethodContext 0xffb3bab4 M BlockClosure>ensure: -1201637524: a(n) BlockClosure 0xffb3bad4 M MethodContext(ContextPart)>handleSignal: -1202719088: a(n) MethodContext 0xffb3baf0 M ProgressNotification(Exception)>signal -1201637840: a(n) ProgressNotification 0xffb3bb08 M ProgressNotification(Exception)>signal: -1201637840: a(n) ProgressNotification 0xffb3bb28 M ProgressNotification class>signal:extra: -1216076964: a(n) ProgressNotification class 0xffb3bb64 M [] in OrderedCollection(Collection)>do:displayingProgress:every: -1202851576: a(n) OrderedCollection 0xffb3bb84 M OrderedCollection>do: -1202851576: a(n) OrderedCollection 0xffb3bbb4 M [] in OrderedCollection(Collection)>do:displayingProgress:every: -1202851576: a(n) OrderedCollection 0xffb3bbdc M [] in MorphicUIManager>displayProgress:at:from:to:during: -1211499496: a(n) MorphicUIManager
...
I'm happy to provide more information if you like and am certainly happy to try another revision if you would like to suggest one.
Ken
Hi Ken,
On Mon, Jan 28, 2013 at 12:19 PM, Ken Causey ken@kencausey.com wrote:
Eliot said:
Hi Ken,
yes, I introduced a regression with the latest check-in that I'll fixsoon. For the moment use version 2672 of the sources. To stop the Bochs plugin being built edit unixbuild/bld/plugins.ext and delete it from there. It being built by default is entirely for my benefit. Apologies.
Thanks Eliot. Unfortunately that doesn't seem to have helped.
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
I deleted my checkout entirely and then
$ svn co http://www.squeakvm.org/svn/**squeak/branches/Cog/@2672http://www.squeakvm.org/svn/squeak/branches/Cog/@2672
And built that (after one failure because I forgot to edit plugins.ext). I haven't analyzed it in detail but it seems be the same issue I had before
Squeak VM version: 4.0-2672 #1 Mon Jan 28 21:08:17 CET 2013 gcc 4.4.5 Built from: CoInterpreter VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-**1088ef4b82d8 Jan 28 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-**1088ef4b82d8 Jan 28 2013 Revision: VM: r2672 http://www.squeakvm.org/svn/**squeak/branches/Coghttp://www.squeakvm.org/svn/squeak/branches/CogPlugins: r2545 http://squeakvm.org/svn/**squeak/trunk/platforms/Cross/**pluginshttp://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
Build host: Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/]
C stack backtrace: /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/squeak[**0x805fb94] /home/kencausey/source/cog/**svn/Cog/unixbuild/bld/squeak[**0x805fe2f] [0xffffe410] [0xb71c97c8]
...
Smalltalk stack dump: 0xffb3ba50 M [] in MorphicUIManager>**displayProgress:at:from:to:**during: -1211499496: a(n) MorphicUIManager 0xffb3ba74 I BlockClosure>cull: -1202719336: a(n) BlockClosure 0xffb3ba94 M [] in MethodContext(ContextPart)>**handleSignal: -1202719088: a(n) MethodContext 0xffb3bab4 M BlockClosure>ensure: -1201637524: a(n) BlockClosure 0xffb3bad4 M MethodContext(ContextPart)>**handleSignal: -1202719088: a(n) MethodContext 0xffb3baf0 M ProgressNotification(**Exception)>signal -1201637840: a(n) ProgressNotification 0xffb3bb08 M ProgressNotification(**Exception)>signal: -1201637840: a(n) ProgressNotification 0xffb3bb28 M ProgressNotification class>signal:extra: -1216076964: a(n) ProgressNotification class 0xffb3bb64 M [] in OrderedCollection(Collection)>**do:displayingProgress:every: -1202851576: a(n) OrderedCollection 0xffb3bb84 M OrderedCollection>do: -1202851576: a(n) OrderedCollection 0xffb3bbb4 M [] in OrderedCollection(Collection)>**do:displayingProgress:every: -1202851576: a(n) OrderedCollection 0xffb3bbdc M [] in MorphicUIManager>**displayProgress:at:from:to:**during: -1211499496: a(n) MorphicUIManager
...
I'm happy to provide more information if you like and am certainly happy to try another revision if you would like to suggest one.
Ken
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
On 01/28/2013 03:42 PM, Ken Causey wrote:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
OK, this
4.0-2672 #1 Mon Jan 28 22:53:27 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Jan 28 2013 VM: r2672 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
gets through the unit tests although with slightly odd results
SUnit Results ------------- 3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests ------------ (AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors ------
(I saw 18,1,0,0 on your 2673 I believe.)
In any case I very much appreciate your assistance and hopefully this is enough to let me get on with the rest of 'all the things'.
Ken
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
I confirm, same crash as Ken with a gcc4.4.3 and gcc4.6.3 compiled VM.
Since analyzing all gcc warnings is like looking for a needle in a haystack, I tried another angle of attack.
So you might be interested in http://smallissimo.blogspot.fr/2013/02/compiling-squeak-cog-virtual-machine-...
Nicolas
2013/1/28 Ken Causey ken@kencausey.com:
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
Really good analysis to figure out that the issue is associated with the -fno-caller-saves option!
I wonder why we are not seeing crashes with the Cog and interpreter VMs that are built locally on box3.squeak.org. These are being compiled with gcc 4.4.5 with latest oscog and trunk sources, and the resulting VMs work well enough to run the Squeak test suites. They are running headless and have a reduced set of plugins, so I wonder if perhaps the problem areas may be in plugins or in the display module?
If you have the patience to try another experiment, could you check and see if an interpreter VM crashes on the same system with the same compiler? Build it with a squeak image from ftp://ftp.squeak.org/4.4/ and file in the script http://squeakci.org/job/InterpreterVM/ws/VMUnixBuild.st to do the build (but first edit VMUnixBuild.st to set exitWhenDone := false).
BTW I agree that the error message is much better in French localization. I would not understand that error message in any language, but it definitely sounds better in French :)
Dave
On Thu, Feb 07, 2013 at 01:18:54AM +0100, Nicolas Cellier wrote:
I confirm, same crash as Ken with a gcc4.4.3 and gcc4.6.3 compiled VM.
Since analyzing all gcc warnings is like looking for a needle in a haystack, I tried another angle of attack.
So you might be interested in http://smallissimo.blogspot.fr/2013/02/compiling-squeak-cog-virtual-machine-...
Nicolas
2013/1/28 Ken Causey ken@kencausey.com:
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
On 7 February 2013 01:00, David T. Lewis lewis@mail.msen.com wrote:
Really good analysis to figure out that the issue is associated with the -fno-caller-saves option!
I wonder why we are not seeing crashes with the Cog and interpreter VMs that are built locally on box3.squeak.org. These are being compiled with gcc 4.4.5 with latest oscog and trunk sources, and the resulting VMs work well enough to run the Squeak test suites. They are running headless and have a reduced set of plugins, so I wonder if perhaps the problem areas may be in plugins or in the display module?
If you have the patience to try another experiment, could you check and see if an interpreter VM crashes on the same system with the same compiler? Build it with a squeak image from ftp://ftp.squeak.org/4.4/ and file in the script http://squeakci.org/job/InterpreterVM/ws/VMUnixBuild.st to do the build (but first edit VMUnixBuild.st to set exitWhenDone := false).
*cough* of course you mean http://build.squeak.org/job/InterpreterVM/ws/VMUnixBuild.st *cough*
frank
BTW I agree that the error message is much better in French localization. I would not understand that error message in any language, but it definitely sounds better in French :)
Dave
On Thu, Feb 07, 2013 at 01:18:54AM +0100, Nicolas Cellier wrote:
I confirm, same crash as Ken with a gcc4.4.3 and gcc4.6.3 compiled VM.
Since analyzing all gcc warnings is like looking for a needle in a haystack, I tried another angle of attack.
So you might be interested in http://smallissimo.blogspot.fr/2013/02/compiling-squeak-cog-virtual-machine-...
Nicolas
2013/1/28 Ken Causey ken@kencausey.com:
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
Hi Dave, I did not have time to test the Smalltalk script, but I compiled an already generated interpreter VM with gcc 4.6.3. Passing the tests didn't cause any crash, so it seems that despite it is relying on some UB, we can still compile with a recent gcc, and that the -fcaller-saves problem only strikes the COG VM...
Nicolas
2013/2/7 David T. Lewis lewis@mail.msen.com:
Really good analysis to figure out that the issue is associated with the -fno-caller-saves option!
I wonder why we are not seeing crashes with the Cog and interpreter VMs that are built locally on box3.squeak.org. These are being compiled with gcc 4.4.5 with latest oscog and trunk sources, and the resulting VMs work well enough to run the Squeak test suites. They are running headless and have a reduced set of plugins, so I wonder if perhaps the problem areas may be in plugins or in the display module?
If you have the patience to try another experiment, could you check and see if an interpreter VM crashes on the same system with the same compiler? Build it with a squeak image from ftp://ftp.squeak.org/4.4/ and file in the script http://squeakci.org/job/InterpreterVM/ws/VMUnixBuild.st to do the build (but first edit VMUnixBuild.st to set exitWhenDone := false).
BTW I agree that the error message is much better in French localization. I would not understand that error message in any language, but it definitely sounds better in French :)
Dave
On Thu, Feb 07, 2013 at 01:18:54AM +0100, Nicolas Cellier wrote:
I confirm, same crash as Ken with a gcc4.4.3 and gcc4.6.3 compiled VM.
Since analyzing all gcc warnings is like looking for a needle in a haystack, I tried another angle of attack.
So you might be interested in http://smallissimo.blogspot.fr/2013/02/compiling-squeak-cog-virtual-machine-...
Nicolas
2013/1/28 Ken Causey ken@kencausey.com:
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
On Mon, Feb 11, 2013 at 10:04:52PM +0100, Nicolas Cellier wrote:
Hi Dave, I did not have time to test the Smalltalk script, but I compiled an already generated interpreter VM with gcc 4.6.3. Passing the tests didn't cause any crash, so it seems that despite it is relying on some UB, we can still compile with a recent gcc, and that the -fcaller-saves problem only strikes the COG VM...
Nicolas
Hi Nicolas,
Thanks a lot for testing this, it is good information.
Dave
2013/2/7 David T. Lewis lewis@mail.msen.com:
Really good analysis to figure out that the issue is associated with the -fno-caller-saves option!
I wonder why we are not seeing crashes with the Cog and interpreter VMs that are built locally on box3.squeak.org. These are being compiled with gcc 4.4.5 with latest oscog and trunk sources, and the resulting VMs work well enough to run the Squeak test suites. They are running headless and have a reduced set of plugins, so I wonder if perhaps the problem areas may be in plugins or in the display module?
If you have the patience to try another experiment, could you check and see if an interpreter VM crashes on the same system with the same compiler? Build it with a squeak image from ftp://ftp.squeak.org/4.4/ and file in the script http://squeakci.org/job/InterpreterVM/ws/VMUnixBuild.st to do the build (but first edit VMUnixBuild.st to set exitWhenDone := false).
BTW I agree that the error message is much better in French localization. I would not understand that error message in any language, but it definitely sounds better in French :)
Dave
On Thu, Feb 07, 2013 at 01:18:54AM +0100, Nicolas Cellier wrote:
I confirm, same crash as Ken with a gcc4.4.3 and gcc4.6.3 compiled VM.
Since analyzing all gcc warnings is like looking for a needle in a haystack, I tried another angle of attack.
So you might be interested in http://smallissimo.blogspot.fr/2013/02/compiling-squeak-cog-virtual-machine-...
Nicolas
2013/1/28 Ken Causey ken@kencausey.com:
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
Nicolas, can i ask you to put essential parts of what you found on cog project issue tracker? So it won't be lost in vain. Because keeping track of everything from multiple sites is error prone :)
http://code.google.com/p/cog/issues/detail?id=120
Nicolas
2013/2/12 Igor Stasenko siguctua@gmail.com:
Nicolas, can i ask you to put essential parts of what you found on cog project issue tracker? So it won't be lost in vain. Because keeping track of everything from multiple sites is error prone :)
-- Best regards, Igor Stasenko.
On 7 February 2013 01:18, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I confirm, same crash as Ken with a gcc4.4.3 and gcc4.6.3 compiled VM.
Since analyzing all gcc warnings is like looking for a needle in a haystack, I tried another angle of attack.
So you might be interested in http://smallissimo.blogspot.fr/2013/02/compiling-squeak-cog-virtual-machine-...
Good find! :)
Nicolas
2013/1/28 Ken Causey ken@kencausey.com:
On 01/28/2013 04:04 PM, Ken Causey wrote:
SUnit Results
3272 run, 3251 passes, 19 expected failures, 1 failures, 0 errors, 1 unexpected passes
Failed Tests
(AllocationTest selector: #testOneGigAllocation) debug. (LocaleTest selector: #testLocaleChanged) debug.
Errors
For what it's worth I get the same results with svn head (2675):
4.0-2673 #1 Mon Jan 28 23:08:31 CET 2013 gcc 4.3.5 CoInterpreter VMMaker.oscog-eem.258 uuid: da1433f1-de50-475f-be33-f462b300a2ea Jan 28 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.256 uuid: bfea3efd-4e81-4e85-922e-cf4f58ee5d64 Jan 28 2013 VM: r2673 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Linux squeak-box4 2.6.32-xenU-7428-x86_64 #4 SMP Mon Nov 19 10:17:25 UTC 2012 x86_64 GNU/Linux plugin path: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/ [default: /home/kencausey/source/cog/svn/Cog/unixbuild/bld/]
Ken
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
Nicolas
On 28 January 2013 23:07, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
I cannot agree more. We also experiencing problems with mac VM now., which builds successfully but crashing right after entering interpret() function.. and no apparent reason (using same sources to build on more recent mac-os version producing stable vm). Also, llvm is another thing: Esteban were trying to use it to build VM, but result is highly unstable VM.
Nicolas
On 2013-02-04, at 08:49, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2013 23:07, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
I cannot agree more.
well you mute them, right?
The behaviour in SmallTalk relies on the underlying framework which you state is C language and full of undefined behaviour...
Doesn't that make the SmallTalk environment Undefined Behavior as well by inheriting the UB from the C layer it builds on?
Or is that just irrational F.U.D. in promotion of SmallTalk by detraction against C?
*both* languages are capable and leave defining behavior to the authoring programmer/coder/software-developer/...
Or at least that is my own understanding...
Belxjander On Feb 4, 2013 5:32 PM, "Camillo Bruni" camillobruni@gmail.com wrote:
On 2013-02-04, at 08:49, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2013 23:07, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the
r2669,
r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/?
If
these don't crash then it might be something to do with gcc 4.4.x.
But
I'd have to take a look, and time is tight right now... But if any of
them do
work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would
have
crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling
gcc
issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large
anyway) seem
to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
I cannot agree more.
well you mute them, right?
On 2013-02-04, at 09:41, Jeremy Kajikawa jeremy.kajikawa@gmail.com wrote:
The behaviour in SmallTalk relies on the underlying framework which you state is C language and full of undefined behaviour...
C consists of a lot of undefined behavior, writing a fast and fully C compliant VM is hard! With each new version of GCC we run into new troubles, since the VM makes assumptions that are actually undefined in the C standards.
Doesn't that make the SmallTalk environment Undefined Behavior as well by inheriting the UB from the C layer it builds on?
exactly it DOES, we try to build our own VM here since 2 years:
result? unstable builds, since with certainty there has never been an automated build. We get random crashes even though our builds are "gree"
Or is that just irrational F.U.D. in promotion of SmallTalk by detraction against C?
*both* languages are capable and leave defining behavior to the authoring programmer/coder/software-developer/...
the question is at which price? and what can we do against it?
=> docuemntation and process is general! - AKA keep the bus factor low, people disappear unexpectedly
=> automated builds help to reduce random hazards => building on different platforms and setups help to avoid wrong usage of undefined behavior => reducing warning messages helps to actually draw the focus on the ones that might cause errors => use an issue tracker for bugs, who knows what has been fixed and hasnt?
On 4 February 2013 08:41, Jeremy Kajikawa jeremy.kajikawa@gmail.com wrote:
The behaviour in SmallTalk relies on the underlying framework which you state is C language and full of undefined behaviour...
That's not quite true. Smalltalk's behaviour is perfectly well defined, in terms of a stack machine. This PARTICULAR VM is built using Slang, a stripped down dialect of Smalltalk that can be mapped quite easily to C.
There is nothing in Smalltalk's definition about how you implement a virtual machine and, in fact, people have implemented a VM in PyPy, while others have run Smalltalk _directly_on_hardware_.
frank
Doesn't that make the SmallTalk environment Undefined Behavior as well by inheriting the UB from the C layer it builds on?
No.
Or is that just irrational F.U.D. in promotion of SmallTalk by detraction against C?
Yes.
frank
*both* languages are capable and leave defining behavior to the authoring programmer/coder/software-developer/...
Or at least that is my own understanding...
Belxjander
On Feb 4, 2013 5:32 PM, "Camillo Bruni" camillobruni@gmail.com wrote:
On 2013-02-04, at 08:49, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2013 23:07, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
I cannot agree more.
well you mute them, right?
2013/2/4 Frank Shearar frank.shearar@gmail.com:
On 4 February 2013 08:41, Jeremy Kajikawa jeremy.kajikawa@gmail.com wrote:
The behaviour in SmallTalk relies on the underlying framework which you state is C language and full of undefined behaviour...
That's not quite true. Smalltalk's behaviour is perfectly well defined, in terms of a stack machine. This PARTICULAR VM is built using Slang, a stripped down dialect of Smalltalk that can be mapped quite easily to C.
There is nothing in Smalltalk's definition about how you implement a virtual machine and, in fact, people have implemented a VM in PyPy, while others have run Smalltalk _directly_on_hardware_.
frank
Doesn't that make the SmallTalk environment Undefined Behavior as well by inheriting the UB from the C layer it builds on?
No.
Or is that just irrational F.U.D. in promotion of SmallTalk by detraction against C?
Yes.
Irrational FUD? No, it's just a question of using the right tool for the job.
You must keep in mind that when you write a VM, you have to deal with low level data representation, and you want to be in control. It's like using kind of bit fields (not the unfortunately unportable ones of C). Then the VM has to perform all kind of bit ops to retrieve data (shift, or, and etc...). Some of these ops can be problematic for signed values (arithmetic vs logical shift, two-complement vs one-complement etc...).
The fact is that with traditional C compilers, some of these ops were reliably well defined for 2-complement machines, maybe not by the standard, but at least by the compiler, and this was the case with old gcc (2.95 & 3.4). So C compiler served very well our goal to have a kind of generic assembly (I think, its original purpose).
It's not the same for more recent version of C compilers: our VM code that used to just work now doesn't. I never said it was the fault of C. Relying on non standard, non supported features is entirely our fault. But we really need these features to program the VM. And these features are well defined at assembly level... That just indicates that the gap between C and assembly has grown a bit.
Of course, it's still possible to use C and keep this fine grain control. But we have to evaluate cost. Well defined constructs are somehow technical and non intuitive, not to say convoluted. That's the only thing I said against C, that the signed arithmetic model is particularly broken, in the sense that it has a plethora of undefined behavior. And I'd like to be proven wrong, but I doubt I'll be. To avoid UB we gonna need plenty of cast to unsigned, even if the nature of underlying data is 2-complement signed. That's far from ideal.
Tracking and correcting has a cost that we did not want to anticipate and that we now face. It's more complex than just fixing the code, since it is generated, we must fix the generator... But the generator is hackish and does not reflect the complexity of underlying C rules... It just used to work, along with traditional compilers... Entirely our fault again for sure, but what to do now? Either we reflect the complex C arithmetic model in the generator - or we patch it like mad to workaround known defects in generated code. In the short term, we will probably hack and patch if we can. Since we also target JIT, and have some progress on this front, we can legitimately wonder if C will still be the right tool in the future.
Nicolas
frank
*both* languages are capable and leave defining behavior to the authoring programmer/coder/software-developer/...
Or at least that is my own understanding...
Belxjander
On Feb 4, 2013 5:32 PM, "Camillo Bruni" camillobruni@gmail.com wrote:
On 2013-02-04, at 08:49, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2013 23:07, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said: > > Hmmm. Sorry to put you to this but what happens when you run the r2669, > r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If > these don't crash then it might be something to do with gcc 4.4.x. But > I'd > have to take a look, and time is tight right now... But if any of them do > work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
I cannot agree more.
well you mute them, right?
On Sat, Jan 26, 2013 at 05:54:00PM -0600, Ken Causey wrote:
Thanks Dave! It's been some years since I did more than configure ; make ; make install when building a VM so I've gotten lazy and my memory has faded significantly.
I know what you mean. I've always been lazy, but this memory fading thing really catches up with you after a while, doesn't it ;-)
Dave
Apologies, please disregard. I was reviewing some old mail files and sent this now-irrelevant message by mistake.
Dave
On Thu, Aug 08, 2013 at 12:21:26AM -0400, David T. Lewis wrote:
On Sat, Jan 26, 2013 at 05:54:00PM -0600, Ken Causey wrote:
Thanks Dave! It's been some years since I did more than configure ; make ; make install when building a VM so I've gotten lazy and my memory has faded significantly.
I know what you mean. I've always been lazy, but this memory fading thing really catches up with you after a while, doesn't it ;-)
Dave
On 07-08-2013, at 9:27 PM, David T. Lewis lewis@mail.msen.com wrote:
Apologies, please disregard. I was reviewing some old mail files and sent this now-irrelevant message by mistake.
Dave
On Thu, Aug 08, 2013 at 12:21:26AM -0400, David T. Lewis wrote:
On Sat, Jan 26, 2013 at 05:54:00PM -0600, Ken Causey wrote:
Thanks Dave! It's been some years since I did more than configure ; make ; make install when building a VM so I've gotten lazy and my memory has faded significantly.
I know what you mean. I've always been lazy, but this memory fading thing really catches up with you after a while, doesn't it ;-)
As you say, this memory fading thing…. wait, what was I saying?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WAF: Warn After the Fact
On 2013-01-26, at 21:52, Ken Causey ken@kencausey.com wrote:
kencausey@squeak-box4:~/source/cog/svn/Cog/unixbuild/bld$ \ ../../platforms/unix/config/configure CC="gcc -m32" CXX="g++ -m32"\ --without-npsqueak CFLAGS="-g -O2 -msse2 -D_GNU_SOURCE \ -D_FILE^J_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 \ -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" LIBS=-lpthread \
myconf.log 2>&1 &
Get rid of the ^J to avoid this:
configure:2174: gcc -m32 -g -O2 -msse2 -D_GNU_SOURCE -D_FILE _OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0 conftest.c -lpthread >&5 gcc: _OFFSET_BITS=64: No such file or directory
- Bert -
Hello,
On Sun, Jan 27, 2013 at 12:52 AM, Ken Causey ken@kencausey.com wrote:
I've been banging my head against building Cog on the primary new Squeak server off and on now for a couple of weeks. This server is 64bit Debian. Note that I don't need and am not trying to build a 64bit VM, a 32bit VM is fine, at least for the time being.
| } configure:2216: error: C compiler cannot create executables See `config.log' for more details.
On Cent OS x64 I have the same problem, and it is solved by installing glibc-devel.i686 packages (yum install glibc-devel.i686)
Regards, Nikolay
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Camillo Bruni -
David T. Lewis -
Derek O'Connell -
Eliot Miranda -
Frank Shearar -
Igor Stasenko -
Jeremy Kajikawa -
Ken Causey -
Nicolas Cellier -
Nikolay Suslov -
tim Rowledge