On Thu, Dec 17, 2015 at 1:43 AM, Ben Coman btc@openinworld.com wrote:
I'm having a go at getting this working with the Spur svn sources per... http://www.mirandabanda.org/cogblog/compiling-the-vm/
@Eliot, I am currently stuck on Spur's requirement for mmap. Could you describe this requirement and any ideas on path to proceed to check compatibilty with these...
https://github.com/rumpkernel/wiki/wiki/Info:-FAQ says "For simplicity reasons, the Rumprun unikernel does not support virtual memory -- unnecessary in a unikernel -- nor does it support signals the traditional way. That means that programs which absolutely depend on things like fork(),execve(), mmap() and sigaction() may not work correctly. In some cases we provide a small amount of cheap emulation for common cases (e.g. mmap(MAP_ANON))"
http://rumpkernel.org/misc/usenix-login-2014/login_1410_03_kantee.pdf says "The more or less only negative effect caused by the lack of virtual memory support is that the mmap() system call cannot be fully handled by a rump kernel. A number of workarounds are possible for applications that absolutely need to use mmap(). For example, the bozohttpd Web server uses mmap() to read the files it serves, so when running bozohttpd on top of a rump kernel, we simply read the mmap’d window into memory at the time the mapping is made instead of gradually faulting pages in. A perfect emulation of mmap() is hard to achieve, but one that works for most practical purposes is easy to achieve"
cheers -ben
P.S. Here is the compilation error...
platforms/unix/vm/sqUnixSpurMemory.c:72:3: error: #error "Spur requires mmap" # error "Spur requires mmap" ^ platforms/unix/vm/sqUnixSpurMemory.c: In function ‘sqAllocateMemory’: platforms/unix/vm/sqUnixSpurMemory.c:108:47: warning: passing argument 3 of ‘sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto’ from incompatible pointer type (roundUpToPage(desiredHeapSize), address, &allocBytes); ^ In file included from platforms/unix/vm/sqUnixSpurMemory.c:33:0: platforms/Cross/vm/sq.h:88:14: note: expected ‘sqInt *’ but argument is of type ‘long unsigned int *’ extern void *sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(sqInt sz, void *minAddr, sqInt *asp); ^ Makefile:276: recipe for target 'sqUnixSpurMemory.o' failed make[1]: *** [sqUnixSpurMemory.o] Error 1 Makefile:407: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
Try running your VM with "-help" and/or check the man page (sorry to be vague, I'm not able to check right now). You should be able to start the VM with malloc to allocate the heap rather than mmap, which should get you around the problem. I can't recall the parameter but it should be in the -help.
Dave
On Thu, Dec 17, 2015 at 1:43 AM, Ben Coman btc@openinworld.com wrote:
I'm having a go at getting this working with the Spur svn sources per... http://www.mirandabanda.org/cogblog/compiling-the-vm/
@Eliot, I am currently stuck on Spur's requirement for mmap. Could you describe this requirement and any ideas on path to proceed to check compatibilty with these...
https://github.com/rumpkernel/wiki/wiki/Info:-FAQ says "For simplicity reasons, the Rumprun unikernel does not support virtual memory -- unnecessary in a unikernel -- nor does it support signals the traditional way. That means that programs which absolutely depend on things like fork(),execve(), mmap() and sigaction() may not work correctly. In some cases we provide a small amount of cheap emulation for common cases (e.g. mmap(MAP_ANON))"
http://rumpkernel.org/misc/usenix-login-2014/login_1410_03_kantee.pdf says "The more or less only negative effect caused by the lack of virtual memory support is that the mmap() system call cannot be fully handled by a rump kernel. A number of workarounds are possible for applications that absolutely need to use mmap(). For example, the bozohttpd Web server uses mmap() to read the files it serves, so when running bozohttpd on top of a rump kernel, we simply read the mmapâd window into memory at the time the mapping is made instead of gradually faulting pages in. A perfect emulation of mmap() is hard to achieve, but one that works for most practical purposes is easy to achieve"
cheers -ben
P.S. Here is the compilation error...
platforms/unix/vm/sqUnixSpurMemory.c:72:3: error: #error "Spur requires mmap" # error "Spur requires mmap" ^ platforms/unix/vm/sqUnixSpurMemory.c: In function âsqAllocateMemoryâ: platforms/unix/vm/sqUnixSpurMemory.c:108:47: warning: passing argument 3 of âsqAllocateMemorySegmentOfSizeAboveAllocatedSizeIntoâ from incompatible pointer type (roundUpToPage(desiredHeapSize), address, &allocBytes); ^ In file included from platforms/unix/vm/sqUnixSpurMemory.c:33:0: platforms/Cross/vm/sq.h:88:14: note: expected âsqInt *â but argument is of type âlong unsigned int *â extern void *sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(sqInt sz, void *minAddr, sqInt *asp); ^ Makefile:276: recipe for target 'sqUnixSpurMemory.o' failed make[1]: *** [sqUnixSpurMemory.o] Error 1 Makefile:407: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
Hi Ben,
On Wed, Dec 16, 2015 at 10:46 AM, Ben Coman btc@openinworld.com wrote:
On Thu, Dec 17, 2015 at 1:43 AM, Ben Coman btc@openinworld.com wrote:
I'm having a go at getting this working with the Spur svn sources per... http://www.mirandabanda.org/cogblog/compiling-the-vm/
@Eliot, I am currently stuck on Spur's requirement for mmap. Could you describe this requirement and any ideas on path to proceed to check compatibilty with these...
The key here is that Spur's heap is segmented. In Unix or Windows we use mmap or its equivalent to obtain memory for additional segments when the heap grows. In a Xen context as I understand it, there is no virtual memory, only segments of memory that Xen will give to an application above it. hence the problem is to mate Xen memory segments to Spur, in which case you will discard the use of mmap. Xen is a new platform; see below.
There are constraints here. The VM assumes the following memory order:
Low addresses: machine code zone new space first heap segment
High addresses subsequent heap segments
So in using memory from Xen you'll want to ask for some amount of memory in the form of segments, and initialise the VM so that the segments are used in line with these constraints. Does that make sense?
Now there's an assumption that the machine code zone, new space and the first heap segment are contiguous, but that's not fundamental, merely historical convenience. As long as the regions are in the order machine code zone < new space < first heap segment things all work. So you may have to rewrite some of the image loading code if you can't obtain a segment large enough to accomodate all of the machine code zone, new space and the first heap segment.
https://github.com/rumpkernel/wiki/wiki/Info:-FAQ
says "For simplicity reasons, the Rumprun unikernel does not support virtual memory -- unnecessary in a unikernel -- nor does it support signals the traditional way. That means that programs which absolutely depend on things like fork(),execve(), mmap() and sigaction() may not work correctly. In some cases we provide a small amount of cheap emulation for common cases (e.g. mmap(MAP_ANON))"
http://rumpkernel.org/misc/usenix-login-2014/login_1410_03_kantee.pdf says "The more or less only negative effect caused by the lack of virtual memory support is that the mmap() system call cannot be fully handled by a rump kernel. A number of workarounds are possible for applications that absolutely need to use mmap(). For example, the bozohttpd Web server uses mmap() to read the files it serves, so when running bozohttpd on top of a rump kernel, we simply read the mmap’d window into memory at the time the mapping is made instead of gradually faulting pages in. A perfect emulation of mmap() is hard to achieve, but one that works for most practical purposes is easy to achieve"
cheers -ben
P.S. Here is the compilation error...
platforms/unix/vm/sqUnixSpurMemory.c:72:3: error: #error "Spur requires mmap" # error "Spur requires mmap" ^ platforms/unix/vm/sqUnixSpurMemory.c: In function ‘sqAllocateMemory’: platforms/unix/vm/sqUnixSpurMemory.c:108:47: warning: passing argument 3 of ‘sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto’ from incompatible pointer type (roundUpToPage(desiredHeapSize), address, &allocBytes); ^ In file included from platforms/unix/vm/sqUnixSpurMemory.c:33:0: platforms/Cross/vm/sq.h:88:14: note: expected ‘sqInt *’ but argument is of type ‘long unsigned int *’ extern void *sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(sqInt sz, void *minAddr, sqInt *asp); ^ Makefile:276: recipe for target 'sqUnixSpurMemory.o' failed make[1]: *** [sqUnixSpurMemory.o] Error 1 Makefile:407: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix. I would implement the relevant support for Xen there-in. I'd also decide whether what I was producing was headful or headless (the latter I presume?).
_,,,^..^,,,_ best, Eliot
On Thu, Dec 17, 2015 at 4:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Wed, Dec 16, 2015 at 10:46 AM, Ben Coman btc@openinworld.com wrote:
On Thu, Dec 17, 2015 at 1:43 AM, Ben Coman btc@openinworld.com wrote:
I'm having a go at getting this working with the Spur svn sources per... http://www.mirandabanda.org/cogblog/compiling-the-vm/
@Eliot, I am currently stuck on Spur's requirement for mmap. Could you describe this requirement and any ideas on path to proceed to check compatibilty with these...
The key here is that Spur's heap is segmented. In Unix or Windows we use mmap or its equivalent to obtain memory for additional segments when the heap grows. In a Xen context as I understand it, there is no virtual memory, only segments of memory that Xen will give to an application above it. hence the problem is to mate Xen memory segments to Spur, in which case you will discard the use of mmap. Xen is a new platform; see below.
There are constraints here. The VM assumes the following memory order:
Low addresses: machine code zone new space first heap segment
High addresses subsequent heap segments
So in using memory from Xen you'll want to ask for some amount of memory in the form of segments, and initialise the VM so that the segments are used in line with these constraints. Does that make sense?
Now there's an assumption that the machine code zone, new space and the first heap segment are contiguous, but that's not fundamental, merely historical convenience. As long as the regions are in the order machine code zone < new space < first heap segment things all work. So you may have to rewrite some of the image loading code if you can't obtain a segment large enough to accomodate all of the machine code zone, new space and the first heap segment.
Makes sense. What is the expected size of that initial segment?
https://github.com/rumpkernel/wiki/wiki/Info:-FAQ says "For simplicity reasons, the Rumprun unikernel does not support virtual memory -- unnecessary in a unikernel -- nor does it support signals the traditional way. That means that programs which absolutely depend on things like fork(),execve(), mmap() and sigaction() may not work correctly. In some cases we provide a small amount of cheap emulation for common cases (e.g. mmap(MAP_ANON))"
http://rumpkernel.org/misc/usenix-login-2014/login_1410_03_kantee.pdf says "The more or less only negative effect caused by the lack of virtual memory support is that the mmap() system call cannot be fully handled by a rump kernel. A number of workarounds are possible for applications that absolutely need to use mmap(). For example, the bozohttpd Web server uses mmap() to read the files it serves, so when running bozohttpd on top of a rump kernel, we simply read the mmap’d window into memory at the time the mapping is made instead of gradually faulting pages in. A perfect emulation of mmap() is hard to achieve, but one that works for most practical purposes is easy to achieve"
cheers -ben
P.S. Here is the compilation error...
platforms/unix/vm/sqUnixSpurMemory.c:72:3: error: #error "Spur requires mmap" # error "Spur requires mmap" ^ platforms/unix/vm/sqUnixSpurMemory.c: In function ‘sqAllocateMemory’: platforms/unix/vm/sqUnixSpurMemory.c:108:47: warning: passing argument 3 of ‘sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto’ from incompatible pointer type (roundUpToPage(desiredHeapSize), address, &allocBytes); ^ In file included from platforms/unix/vm/sqUnixSpurMemory.c:33:0: platforms/Cross/vm/sq.h:88:14: note: expected ‘sqInt *’ but argument is of type ‘long unsigned int *’ extern void *sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(sqInt sz, void *minAddr, sqInt *asp); ^ Makefile:276: recipe for target 'sqUnixSpurMemory.o' failed make[1]: *** [sqUnixSpurMemory.o] Error 1 Makefile:407: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix. I would implement the relevant support for Xen there-in. I'd also decide whether what I was producing was headful or headless (the latter I presume?).
I think the platform is more "rumprun" which is the first layer Spur deals with, then there are a few options below rumprun that might be better to capture as a build... .../platforms/rumprun ../build.xenrumprun.32x86 ../build.xenrumprun.32ARM ../build.baremetalrumprun.32x86 ../build.baremetalrumprun.32ARM ../build.KVMrumprun.32x86 ../build.KVMrumprun.32ARM
or maybe ../build.rumprun.Xen32x86 ../build.rumprun.Xen32ARM ../build.rumprun.baremetal32x86 ../build.rumprun.baremetal32ARM ../build.rumprun.KVM32x86 ../build.rumprun.KVM32ARM
cheers -ben
On Wed, Dec 16, 2015 at 3:20 PM, Ben Coman btc@openinworld.com wrote:
On Thu, Dec 17, 2015 at 4:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
There are constraints here. The VM assumes the following memory order:
Low addresses: machine code zone new space first heap segment
High addresses subsequent heap segments
I know new space < old space is relied on for store buffer checks. Is the relative order of the code zone and the heap ever used?
Thinking long term, this reliance on ordering is bad for address space randomization or having multiple heaps in the same process (e.g., having concurrent actors with fast messaging). The Dart VM uses object alignment to distinguish object age, though it doesn't have immediate characters or floats contending for that bit.
On Wed, Dec 16, 2015 at 10:34 PM, Ryan Macnak rmacnak@gmail.com wrote:
On Wed, Dec 16, 2015 at 3:20 PM, Ben Coman btc@openinworld.com wrote:
On Thu, Dec 17, 2015 at 4:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
There are constraints here. The VM assumes the following memory order:
Low addresses: machine code zone new space first heap segment
High addresses subsequent heap segments
I know new space < old space is relied on for store buffer checks. Is the relative order of the code zone and the heap ever used?
Rather than used, it is coped with. See SpurMemoryManager>>isYoungObject: & isReallyYoungObject: & Spur[32|64]BitCoMemoryManager>>isReallyYoungObject:. The code zone can go anywhere, but if it goes below new space (as it does currently) then the scavenger needs to use isReallyYoungObject: so as not to be confused by the CogMethod references in cogged CompiledMethods.
Thinking long term, this reliance on ordering is bad for address space
randomization or having multiple heaps in the same process (e.g., having concurrent actors with fast messaging). The Dart VM uses object alignment to distinguish object age, though it doesn't have immediate characters or floats contending for that bit.
Agreed. But it is nice to be able to use a single bounds check. I'm happy to maintain two versions when address randomisation and/ior unikernels force two checks.
The alignment issue is trickier than that. Right now Spur has an 8 byte alignment, so bit 1 << 3 can vary. Aligning object headers on a 16 byte boundary, thereby allowing bit 1 << 3 to be used to mark age, would involve padding half of the objects with another 8 byte word, and that's of the order of a 7% hit on memory usage in 64-bits and 6% in 32-bits (*). So while the alignment trick is fast to test I don't think it pays for itself.
(*) surprised me, but that's what I measured. Since Spur rounds object up to 8 bytes, a 1 inst var 32-bit obj takes the same size as a 2 inst var 32-bit obj. So I guess that this rounding has the effect of ending up with more 32-bit objects aligned on a 16-byte boundary than 64-bit ones. That seems to be the case; in my reader image 141871 32-bit objects need rounding up whereas 232742 64-bit ones do. In my reader image there are 384388 64-bit objects and 413845 32-bit ones. I guess that means 29457 fewer objects due to the larger immediate range and immediate floating point. Not too shabby :-) [but it's late; take these numbers with a grain of salt]
_,,,^..^,,,_ best, Eliot
On Thu, Dec 17, 2015 at 7:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix. I would implement the relevant support for Xen there-in. I'd also decide whether what I was producing was headful or headless (the latter I presume?).
I made a little progress on this, duplicating the unix tree and updating the required paths within the various config files to get back to the same point " # error Spur requires mmap" Now I notice that sqUnixSpurMemory.c contains...
#if SPURVM # if TEST_MEMORY int main() { ... } # endif /* TEST_MEMORY */
which seems like a good starting point to attack this - but I've spent two night trying to wrangle autoconf to produce an executable for this. Can someone share a script for how to use this test frame?
cheers -ben
On Thu, Dec 17, 2015 at 7:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix. I would implement the relevant support for Xen there-in.
As I understand it, making a new platform requires I need to modify configure.ac, and subsequently run autoconf. So I tried using autoconf before making any changes. The following works before running autoconf...
mkdir oscogvm ; cd oscogvm svn co http://www.squeakvm.org/svn/squeak/branches/Cog/platforms svn co http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32x86 svn co http://www.squeakvm.org/svn/squeak/branches/Cog/src svn co http://www.squeakvm.org/svn/squeak/branches/Cog/spursrc cd .. ; cp -r oscogvm oscogvm.orig cd oscogvm/build.linux32x86/squeak.cog.spur/build.debug ./mvm
But after autoconf...
cd oscogvm/platforms/unix/config autoconf cd oscogvm/build.linux32x86/squeak.cog.spur/build.debug ./mvm
it fails like this... gcc -m32 -g3 -O0 -fwrapv -DDEBUGVM=1 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0 -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/ben/Repos/minimal-oscog/build.linux32x86/squeak.cog.spur/build.debug -I/home/ben/Repos/minimal-oscog/build.linux32x86/squeak.cog.spur/build.debug -I/home/ben/Repos/minimal-oscog/platforms/unix/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/vm -I/home/ben/Repos/minimal-oscog/spursrc/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/vm -I/home/ben/Repos/minimal-oscog/platforms/unix/vm -I/home/ben/Repos/minimal-oscog/spursrc/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/plugins/FilePlugin -I/home/ben/Repos/minimal-oscog/platforms/unix/plugins/B3DAcceleratorPlugin @X_INCLUDES@ -c -o gcc3x-cointerp.o /home/ben/Repos/minimal-oscog/spursrc/vm/gcc3x-cointerp.c gcc: error: @X_INCLUDES@: No such file or directory Makefile:229: recipe for target 'gcc3x-cointerp.o' failed make[1]: *** [gcc3x-cointerp.o] Error 1 Makefile:405: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
In oscogvm/build.linux32x86/squeak.cog.spur/build.debug/Makefile I find... ------- SOFLAGS= @SOFLAGS@ BITBLT_OBJS= @BITBLT_OBJS@ IA32ABI_OBJS= @IA32ABI_OBJS@ VM_DISPX11_OBJS=@VM_DISPX11_OBJS@ BITBLT_FLAGS= @BITBLT_FLAGS@ VM_DISPX11_BITBLT_FLAGS= @VM_DISPX11_BITBLT_FLAGS@ ARM_ARCH= @ARM_ARCH@ LIBM_CFLAGS= @LIBM_CFLAGS@
X_CFLAGS= @X_CFLAGS@ X_INCLUDES= @X_INCLUDES@ X_LIBS= @X_LIBS@
LIB_UUID= @LIB_UUID@
FFI_DIR= @FFI_DIR@ FFI_C= @FFI_C@ FFI_S= @FFI_S@ FFI_O= @FFI_O@
PYLIBPATH= @PYLIBPATH@ PYINCLUDES= @PYINCLUDES@
I've learnt [1] this seems related to autoconf AC_SUBST(). and maybe the substitution is not being done. Using... find oscogvm -name .svn -prune -o -type f -exec grep -H $SEARCH {} ; | grep SUBST
platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(BITBLT_OBJS, $bitblt_objs) platforms/unix/plugins/IA32ABI/acinclude.m4: AC_SUBST(IA32ABI_OBJS, $ia32abi_objs) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(VM_DISPX11_OBJS, $vm_dispx11_objs) platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(BITBLT_FLAGS, $bitblt_flags) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(VM_DISPX11_BITBLT_FLAGS, $vm_dispx11_bitblt_flags) platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(ARM_ARCH, $arm_arch) platforms/unix/plugins/FloatMathPlugin/acinclude.m4: AC_SUBST(LIBM_CFLAGS, $libm_cflags) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_CFLAGS) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_INCLUDES) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_LIBS) platforms/unix/plugins/UUIDPlugin/acinclude.m4: AC_SUBST(LIB_UUID)
FFI_DIR nothing found FFI_C nothing found FFI_S nothing found FFI_O nothing found PYLIBPATH nothing found PYINCLUDES nothing found
Am I doing something obviously wrong running autoconf? Anyone got any tips on how to approach tracking this down? Anyway, this is making me wary of putting effort into *learning* and troubleshooting autoconf when the path forward seems CMakeVMMakerSqueak. btw, where can I find that?
cheers -ben
Hi Ben,
I can't help much at the moment but I have found that the oscog tree's autoconfig only works if made on certain versions. It works in CentOS 5.3 32-bit but not in CentOS 6.5 (the only two I've tried). So you might want to try generating the configure script on something ancient.
_,,,^..^,,,_ (phone)
On Dec 24, 2015, at 2:14 PM, Ben Coman btc@openinworld.com wrote:
On Thu, Dec 17, 2015 at 7:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote: If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix. I would implement the relevant support for Xen there-in.
As I understand it, making a new platform requires I need to modify configure.ac, and subsequently run autoconf. So I tried using autoconf before making any changes. The following works before running autoconf...
mkdir oscogvm ; cd oscogvm svn co http://www.squeakvm.org/svn/squeak/branches/Cog/platforms svn co http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32x86 svn co http://www.squeakvm.org/svn/squeak/branches/Cog/src svn co http://www.squeakvm.org/svn/squeak/branches/Cog/spursrc cd .. ; cp -r oscogvm oscogvm.orig cd oscogvm/build.linux32x86/squeak.cog.spur/build.debug ./mvm
But after autoconf...
cd oscogvm/platforms/unix/config autoconf cd oscogvm/build.linux32x86/squeak.cog.spur/build.debug ./mvm
it fails like this... gcc -m32 -g3 -O0 -fwrapv -DDEBUGVM=1 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0 -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/ben/Repos/minimal-oscog/build.linux32x86/squeak.cog.spur/build.debug -I/home/ben/Repos/minimal-oscog/build.linux32x86/squeak.cog.spur/build.debug -I/home/ben/Repos/minimal-oscog/platforms/unix/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/vm -I/home/ben/Repos/minimal-oscog/spursrc/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/vm -I/home/ben/Repos/minimal-oscog/platforms/unix/vm -I/home/ben/Repos/minimal-oscog/spursrc/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/plugins/FilePlugin -I/home/ben/Repos/minimal-oscog/platforms/unix/plugins/B3DAcceleratorPlugin @X_INCLUDES@ -c -o gcc3x-cointerp.o /home/ben/Repos/minimal-oscog/spursrc/vm/gcc3x-cointerp.c gcc: error: @X_INCLUDES@: No such file or directory Makefile:229: recipe for target 'gcc3x-cointerp.o' failed make[1]: *** [gcc3x-cointerp.o] Error 1 Makefile:405: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
In oscogvm/build.linux32x86/squeak.cog.spur/build.debug/Makefile I find...
SOFLAGS= @SOFLAGS@ BITBLT_OBJS= @BITBLT_OBJS@ IA32ABI_OBJS= @IA32ABI_OBJS@ VM_DISPX11_OBJS=@VM_DISPX11_OBJS@ BITBLT_FLAGS= @BITBLT_FLAGS@ VM_DISPX11_BITBLT_FLAGS= @VM_DISPX11_BITBLT_FLAGS@ ARM_ARCH= @ARM_ARCH@ LIBM_CFLAGS= @LIBM_CFLAGS@
X_CFLAGS= @X_CFLAGS@ X_INCLUDES= @X_INCLUDES@ X_LIBS= @X_LIBS@
LIB_UUID= @LIB_UUID@
FFI_DIR= @FFI_DIR@ FFI_C= @FFI_C@ FFI_S= @FFI_S@ FFI_O= @FFI_O@
PYLIBPATH= @PYLIBPATH@ PYINCLUDES= @PYINCLUDES@
I've learnt [1] this seems related to autoconf AC_SUBST(). and maybe the substitution is not being done. Using... find oscogvm -name .svn -prune -o -type f -exec grep -H $SEARCH {} ; | grep SUBST
platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(BITBLT_OBJS, $bitblt_objs) platforms/unix/plugins/IA32ABI/acinclude.m4: AC_SUBST(IA32ABI_OBJS, $ia32abi_objs) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(VM_DISPX11_OBJS, $vm_dispx11_objs) platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(BITBLT_FLAGS, $bitblt_flags) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(VM_DISPX11_BITBLT_FLAGS, $vm_dispx11_bitblt_flags) platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(ARM_ARCH, $arm_arch) platforms/unix/plugins/FloatMathPlugin/acinclude.m4: AC_SUBST(LIBM_CFLAGS, $libm_cflags) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_CFLAGS) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_INCLUDES) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_LIBS) platforms/unix/plugins/UUIDPlugin/acinclude.m4: AC_SUBST(LIB_UUID)
FFI_DIR nothing found FFI_C nothing found FFI_S nothing found FFI_O nothing found PYLIBPATH nothing found PYINCLUDES nothing found
Am I doing something obviously wrong running autoconf? Anyone got any tips on how to approach tracking this down? Anyway, this is making me wary of putting effort into *learning* and troubleshooting autoconf when the path forward seems CMakeVMMakerSqueak. btw, where can I find that?
cheers -ben
okay, that helps to know. cheers -ben
On Fri, Dec 25, 2015 at 6:21 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
I can't help much at the moment but I have found that the oscog tree's autoconfig only works if made on certain versions. It works in CentOS 5.3 32-bit but not in CentOS 6.5 (the only two I've tried). So you might want to try generating the configure script on something ancient.
_,,,^..^,,,_ (phone)
On Dec 24, 2015, at 2:14 PM, Ben Coman btc@openinworld.com wrote:
On Thu, Dec 17, 2015 at 7:13 AM, Eliot Miranda eliot.miranda@gmail.com wrote: If I were you I would create a new platform, xen, under platforms, being a sibling of platforms/unix. I would implement the relevant support for Xen there-in.
As I understand it, making a new platform requires I need to modify configure.ac, and subsequently run autoconf. So I tried using autoconf before making any changes. The following works before running autoconf...
mkdir oscogvm ; cd oscogvm svn co http://www.squeakvm.org/svn/squeak/branches/Cog/platforms svn co http://www.squeakvm.org/svn/squeak/branches/Cog/build.linux32x86 svn co http://www.squeakvm.org/svn/squeak/branches/Cog/src svn co http://www.squeakvm.org/svn/squeak/branches/Cog/spursrc cd .. ; cp -r oscogvm oscogvm.orig cd oscogvm/build.linux32x86/squeak.cog.spur/build.debug ./mvm
But after autoconf...
cd oscogvm/platforms/unix/config autoconf cd oscogvm/build.linux32x86/squeak.cog.spur/build.debug ./mvm
it fails like this... gcc -m32 -g3 -O0 -fwrapv -DDEBUGVM=1 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0 -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/ben/Repos/minimal-oscog/build.linux32x86/squeak.cog.spur/build.debug -I/home/ben/Repos/minimal-oscog/build.linux32x86/squeak.cog.spur/build.debug -I/home/ben/Repos/minimal-oscog/platforms/unix/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/vm -I/home/ben/Repos/minimal-oscog/spursrc/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/vm -I/home/ben/Repos/minimal-oscog/platforms/unix/vm -I/home/ben/Repos/minimal-oscog/spursrc/vm -I/home/ben/Repos/minimal-oscog/platforms/Cross/plugins/FilePlugin -I/home/ben/Repos/minimal-oscog/platforms/unix/plugins/B3DAcceleratorPlugin @X_INCLUDES@ -c -o gcc3x-cointerp.o /home/ben/Repos/minimal-oscog/spursrc/vm/gcc3x-cointerp.c gcc: error: @X_INCLUDES@: No such file or directory Makefile:229: recipe for target 'gcc3x-cointerp.o' failed make[1]: *** [gcc3x-cointerp.o] Error 1 Makefile:405: recipe for target 'vm/vm.a' failed make: *** [vm/vm.a] Error 2
In oscogvm/build.linux32x86/squeak.cog.spur/build.debug/Makefile I find...
SOFLAGS= @SOFLAGS@ BITBLT_OBJS= @BITBLT_OBJS@ IA32ABI_OBJS= @IA32ABI_OBJS@ VM_DISPX11_OBJS=@VM_DISPX11_OBJS@ BITBLT_FLAGS= @BITBLT_FLAGS@ VM_DISPX11_BITBLT_FLAGS= @VM_DISPX11_BITBLT_FLAGS@ ARM_ARCH= @ARM_ARCH@ LIBM_CFLAGS= @LIBM_CFLAGS@
X_CFLAGS= @X_CFLAGS@ X_INCLUDES= @X_INCLUDES@ X_LIBS= @X_LIBS@
LIB_UUID= @LIB_UUID@
FFI_DIR= @FFI_DIR@ FFI_C= @FFI_C@ FFI_S= @FFI_S@ FFI_O= @FFI_O@
PYLIBPATH= @PYLIBPATH@ PYINCLUDES= @PYINCLUDES@
I've learnt [1] this seems related to autoconf AC_SUBST(). and maybe the substitution is not being done. Using... find oscogvm -name .svn -prune -o -type f -exec grep -H $SEARCH {} ; | grep SUBST
platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(BITBLT_OBJS, $bitblt_objs) platforms/unix/plugins/IA32ABI/acinclude.m4: AC_SUBST(IA32ABI_OBJS, $ia32abi_objs) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(VM_DISPX11_OBJS, $vm_dispx11_objs) platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(BITBLT_FLAGS, $bitblt_flags) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(VM_DISPX11_BITBLT_FLAGS, $vm_dispx11_bitblt_flags) platforms/unix/plugins/BitBltPlugin/acinclude.m4: AC_SUBST(ARM_ARCH, $arm_arch) platforms/unix/plugins/FloatMathPlugin/acinclude.m4: AC_SUBST(LIBM_CFLAGS, $libm_cflags) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_CFLAGS) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_INCLUDES) platforms/unix/vm-display-X11/acinclude.m4: AC_SUBST(X_LIBS) platforms/unix/plugins/UUIDPlugin/acinclude.m4: AC_SUBST(LIB_UUID)
FFI_DIR nothing found FFI_C nothing found FFI_S nothing found FFI_O nothing found PYLIBPATH nothing found PYINCLUDES nothing found
Am I doing something obviously wrong running autoconf? Anyone got any tips on how to approach tracking this down? Anyway, this is making me wary of putting effort into *learning* and troubleshooting autoconf when the path forward seems CMakeVMMakerSqueak. btw, where can I find that?
cheers -ben
vm-dev@lists.squeakfoundation.org