Vm-dev July 2018

vm-dev@lists.squeakfoundation.org

21 participants
55 discussions

[OpenSmalltalk/opensmalltalk-vm] 2eb250: Make sqUnixHostWindowPlugin.c compile on 64-bit sy...
by GitHub 24 Jul '18

24 Jul '18

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 2eb250bb4ad8c03b4ef24a413b66e46c6bdafc4b https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2eb250bb4ad8c03b4e… Author: user <user(a)user.user> Date: 2018-07-20 (Fri, 20 Jul 2018) Changed paths: M build.linux64x64/newspeak.cog.spur/plugins.int M build.linux64x64/newspeak.sista.spur/plugins.int M build.linux64x64/newspeak.stack.spur/plugins.int M build.linux64x64/nsnac.cog.spur/plugins.int M build.linux64x64/squeak.cog.spur.immutability/plugins.int M build.linux64x64/squeak.cog.spur/plugins.int M build.linux64x64/squeak.stack.spur/plugins.int M platforms/unix/plugins/HostWindowPlugin/sqUnixHostWindowPlugin.c Log Message: ----------- Make sqUnixHostWindowPlugin.c compile on 64-bit systems And readd HostWindowPlugin to builds, especially to those which had it before 6666edcf648bdf5e45140d27bcd27d355e68f6a4. Commit: c337a66112e06b2932af40ba1254127fa66bf44e https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c337a66112e06b2932… Author: Tobias Pape <krono(a)users.noreply.github.com> Date: 2018-07-24 (Tue, 24 Jul 2018) Changed paths: M build.linux64x64/newspeak.cog.spur/plugins.int M build.linux64x64/newspeak.sista.spur/plugins.int M build.linux64x64/newspeak.stack.spur/plugins.int M build.linux64x64/nsnac.cog.spur/plugins.int M build.linux64x64/squeak.cog.spur.immutability/plugins.int M build.linux64x64/squeak.cog.spur/plugins.int M build.linux64x64/squeak.stack.spur/plugins.int M platforms/unix/plugins/HostWindowPlugin/sqUnixHostWindowPlugin.c Log Message: ----------- Merge pull request #273 from smalltalking/Cog Make sqUnixHostWindowPlugin.c compile on 64-bit systems Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/8085115bf8c7...c3… **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019.

1 0

[OpenSmalltalk/opensmalltalk-vm] Make sqUnixHostWindowPlugin.c compile on 64-bit systems (#273)
by smalltalking 24 Jul '18

24 Jul '18

And readd HostWindowPlugin to builds, especially to those which had it before 6666edcf648bdf5e45140d27bcd27d355e68f6a4. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/273 -- Commit Summary -- * Make sqUnixHostWindowPlugin.c compile on 64-bit systems -- File Changes -- M build.linux64x64/newspeak.cog.spur/plugins.int (2) M build.linux64x64/newspeak.sista.spur/plugins.int (2) M build.linux64x64/newspeak.stack.spur/plugins.int (2) M build.linux64x64/nsnac.cog.spur/plugins.int (2) M build.linux64x64/squeak.cog.spur.immutability/plugins.int (2) M build.linux64x64/squeak.cog.spur/plugins.int (2) M build.linux64x64/squeak.stack.spur/plugins.int (2) M platforms/unix/plugins/HostWindowPlugin/sqUnixHostWindowPlugin.c (42) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/273.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/273.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/273

2 1

[OpenSmalltalk/opensmalltalk-vm] Add fflush to sqFileTruncate to make FileHandleTest green on (my) 64 … (#271)
by marfrit 22 Jul '18

22 Jul '18

As discussed in thread 5264ee14-637f-9f39-b616-563a0177d029(a)reauktion.de on vm-dev As this is my very first PR ever, I am not 100% sure everything is correct. If not, please indicate the mistake that has been made. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271 -- Commit Summary -- * Add fflush to sqFileTruncate to make FileHandleTest green on (my) 64 bit platform -- File Changes -- M platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c (1) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271

2 4

[OpenSmalltalk/opensmalltalk-vm] 28152d: Add fflush to sqFileTruncate to make FileHandleTes...
by GitHub 22 Jul '18

22 Jul '18

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 28152db474330cd7f3cf76381ce18b7e50f07539 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/28152db474330cd7f3… Author: Markus Fritsche <mfritsche(a)reauktion.de> Date: 2018-07-09 (Mon, 09 Jul 2018) Changed paths: M platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c Log Message: ----------- Add fflush to sqFileTruncate to make FileHandleTest green on (my) 64 bit platform Commit: 8085115bf8c75b6815d81854002f2f4e521550cc https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/8085115bf8c75b6815… Author: akgrant43 <akgrant(a)gmail.com> Date: 2018-07-22 (Sun, 22 Jul 2018) Changed paths: M platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c Log Message: ----------- Merge pull request #271 from marfrit/Cog Add fflush to sqFileTruncate. This is required since FILE* data structures can cache data, and a subsequent access by fd (file descriptor) may not see the latest contents. Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/97b799c62028...80… **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019.

1 0

[OpenSmalltalk/opensmalltalk-vm] SSL segmentation fault (libssl 1.0.0) (#260)
by smalltalking 20 Jul '18

20 Jul '18

The VM built by travis (201805090836, 64-bit Squeak Cog Spur) segfaults when creating an SSL connection. Here is a stack trace from gdb: > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00007ffff296132a in sqVerifyNameInner (ssl=ssl@entry=0x89b3e0, cert=cert@entry=0x8abdb0, serverName=0x89bad0, serverNameLength=serverNameLength@entry=13, matchType=matchType@entry=2) > at /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc:106 > #2 0x00007ffff29614ab in sqVerifyDNS (ssl=ssl@entry=0x89b3e0, cert=cert@entry=0x8abdb0, serverName=<optimized out>, serverNameLength=serverNameLength@entry=13) > at /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc:94 > #3 0x00007ffff2961e3f in sqConnectSSL (handle=handle@entry=1, srcBuf=srcBuf@entry=0x1025330 "\026\003\003", srcLen=srcLen@entry=279, dstBuf=dstBuf@entry=0x1020b88 "\026\003\003", dstLen=<optimized out>) > at /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc:454 > #4 0x00007ffff295de2f in primitiveConnect () at /home/travis/build/OpenSmalltalk/opensmalltalk-vm/src/plugins/SqueakSSL/SqueakSSL.c:217 This happens on Ubuntu 14.04 (libssl1.0.0). I presume travis had a newer version of openssl, and the different value of OPENSSL_VERSION_NUMBER during compilation time was enough to make some functions, like _sqo_sk_GENERAL_NAME_num_ be linked to null. It's not exactly clear how the overlay works, so I just tried a few functions and got the following results: > (gdb) print sqo_X509_get_ext_d2i > $3 = (void *(*)(X509 *, int, int *, int *)) 0x7ffff2440a90 <X509_get_ext_d2i> > (gdb) print sqo_sk_GENERAL_NAME_num > No symbol "sqo_sk_GENERAL_NAME_num" in current context. > (gdb) print sqo_sk_GENERAL_NAME_value > No symbol "sqo_sk_GENERAL_NAME_value" in current context. > (gdb) print sqVerifySAN > $6 = {sqInt (sqSSL *, const GENERAL_NAME *, const void *, const size_t, const int)} 0x7ffff29610f0 <sqVerifySAN> > (gdb) print sk_GENERAL_NAME_num > No symbol "sk_GENERAL_NAME_num" in current context. > (gdb) print sqo_SKM_sk_num > No symbol "sqo_SKM_sk_num" in current context. > (gdb) print sqo_sk_num > $7 = (int (*)(const _STACK *)) 0x0 > (gdb) print sk_num > $8 = {<text variable, no debug info>} 0x7ffff24064c0 <sk_num> If you need any further information, let me know. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260

2 6

RISC-V J Extension
by Jecel Assumpcao Jr. 16 Jul '18

16 Jul '18

I am back after a forced vacation (surgery) and last Thursday I participated in a meeting of the J extension for RISC-V. The idea of that extension is to support dynamic languages like Java and Javascript (hence the "J") and I hope will also be good for OpenSmalltalk. The current focus of the group is a small, but important detail which they call "atomic instruction fetch". RISC-V supports conherence between data caches in a multicore system, but depends on software to avoid problems with the instruction caches. So if two or more cores share a single compiled code cache in main memory and one of them makes changes to that cache (as a result of an inline cache miss, for example) then another core might see the old version of the code, or (even worse) a mix of the old and new versions. There is a separate group working on debugging features for RISC-V and I suggested that dealing with execution counters for adaptive compilation might overlap with whatever they come up with. So far I don't think this work will help OpenSmalltalk much, but I will continue to keep track and if I am able to extract data about our VM that might be interesting for that group I will pass it on to them. Boris Shingarov is part of that group and wanted to talk to me at this year's ESUG. It is very unlikely that I will be able to go, but if anyone here will be there it would be nice to discuss what RISC-V and our VM could benifit from each other. My own project has gone in a different direction than I described in March so I no longer have the same personal interest in the J extension, but I still plan to help in any way I can. -- Jecel

1 0

musing on StackInterpreter FreeRTOS VM target
by Ben Coman 14 Jul '18

14 Jul '18

Just sharing something thats been circling my head for a while about a possible OpenSmalltalk based IoT platform. Many micro-controllers support FreeRTOS https://www.freertos.org/RTOS_ports.html including the ARMv7 https://www.freertos.org/FreeRTOS_Features.html and the ESP32 (based on Cadence's Tensilica Xtensa LX6) https://www.espressif.com/en/media_overview/news/espressifs-esp32-support-a… Of particular interest is Amazon's adoption of FreeRTOS and its change of license from GPLv2 to MIT. https://aws.amazon.com/blogs/opensource/announcing-freertos-kernel-v10/ If a "thing" is not doing graphics, then the StackInterpreter may be sufficient for many IoT applications. Having a FreeRTOS build target for the StackInterpreter might open the opportunity to have our Images running as the *only* application on a wide variety of embedded systems. A tight Edit-Compile-Run-Debug cycle using the TelePharo remote tools might be very compelling versus the usual Edit-Compile-Download-Boot-Run-BlindGuessDebug cycle. I'd expect interest that starts with the hobby-maker community, might later extend into the lucrative industrial control market in competition with traditional PLCs. Maybe getting the StackInterpreter running on a new platform could make a good advanced-student project? For starters, there seems a simulator here (I haven't used it) https://www.freertos.org/FreeRTOS-simulator-for-Linux.html which raises one question... I understand the VM has a problem with some simulators but is that more a problem for the JIT part of Cog than the StackInterpreter? cheers -ben

2 1

FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux
by Markus Fritsche 13 Jul '18

13 Jul '18

The above test fails for me. The assert fails since the result of handle size is 5, not 3 as expected. I tested on 32 bit Windows, 32 bit Linux (ext4) and 64 bit Linux (btrfs), and only the 64 bit version fails. As by http://stackoverflow.com/questions/13494417/ftruncate-on-file-opened-with-f… - a file descriptor needs to be flushed before being truncated. It seems to be coincidence that this has worked on 32 bit systems. The FilePlugin doesn't do that. Should the FileHandle class be changed for this, the Plugin code, or is the test invalid? Kind regards Markus

3 11

[OpenSmalltalk/opensmalltalk-vm] ByteString(Object)>shallowCopy segfaults (#272)
by Fabio Niephaus 12 Jul '18

12 Jul '18

Another random segfault, this time happening in `ByteString(Object)>shallowCopy`. Steps to reproduce: unknown. Stacktrace ([Full Travis log](https://travis-ci.org/hpi-swa-teaching/SWT18-Project-13/jobs/396783693…): ``` Smalltalk stack dump: 0xbff69e1c M ByteString(Object)>shallowCopy 0x4b0c8a8: a(n) ByteString 0xbff69e34 M ByteString(Object)>copy 0x4b0c8a8: a(n) ByteString 0xbff69e4c M ByteString(String)>withSqueakLineEndings 0x4b0c8a8: a(n) ByteString 0xbff69e64 M MCMethodDefinition>initializeWithClassName:classIsMeta:selector:category:timeStamp:source: 0x1df45a0: a(n) MCMethodDefinition 0xbff69e98 M MCMethodDefinition class>className:classIsMeta:selector:category:timeStamp:source: 0x26f3520: a(n) MCMethodDefinition class 0xbff69eec M [] in MCFileTreeStCypressReader>addMethodDefinitionsForClass:methodProperties:in:extensionMethod: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff69f10 M [] in MultiByteFileStream class(FileStream class)>detectFile:do: 0x308eac0: a(n) MultiByteFileStream class 0xbff69f30 M BlockClosure>ensure: 0x1df47f8: a(n) BlockClosure 0xbff69f50 M MultiByteFileStream class(FileStream class)>detectFile:do: 0x308eac0: a(n) MultiByteFileStream class 0xbff69f70 M MultiByteFileStream class(FileStream class)>readOnlyFileNamed:do: 0x308eac0: a(n) MultiByteFileStream class 0xbff69f90 M UnixFileDirectory(FileDirectory)>readOnlyFileNamed:do: 0x1df4930: a(n) UnixFileDirectory 0xbff69fb0 M DirectoryEntryFile>readStreamDo: 0x1df4970: a(n) DirectoryEntryFile 0xbff69fdc M [] in MCFileTreeStCypressReader>addMethodDefinitionsForClass:methodProperties:in:extensionMethod: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6a000 M Array(SequenceableCollection)>do: 0x1df4ab8: a(n) Array 0xbff6a02c M [] in MCFileTreeStCypressReader>addMethodDefinitionsForClass:methodProperties:in:extensionMethod: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cdf8 M Array(SequenceableCollection)>do: 0x1df5208: a(n) Array 0xbff6ce14 M MCFileTreeStCypressReader>addMethodDefinitionsForClass:methodProperties:in:extensionMethod: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6ce3c M MCFileTreeStCypressReader>addMethodDefinitionsForClass:methodProperties:in: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6ce74 M MCFileTreeStCypressReader>addClassAndMethodDefinitionsFromEntry: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6ce90 M [] in MCFileTreeStCypressReader>addClassAndMethodDefinitionsFromDirectory: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6ceb4 M Array(SequenceableCollection)>do: 0x1df5428: a(n) Array 0xbff6ced0 M MCFileTreeStCypressReader>addClassAndMethodDefinitionsFromDirectory: 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cef4 M MCFileTreeStCypressReader>loadDefinitions 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cf14 I MCFileTreeStCypressReader(MCVersionReader)>definitions 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cf38 I MCFileTreeStCypressReader(MCVersionReader)>snapshot 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cf68 I MCFileTreeStCypressReader>basicVersion 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cf80 M MCFileTreeStCypressReader(MCVersionReader)>version 0x1df4660: a(n) MCFileTreeStCypressReader 0xbff6cf98 M [] in MCFileTreeRepository(MCFileBasedRepository)>loadVersionFromFileNamed: 0x4896708: a(n) MCFileTreeRepository 0xbff6cfc8 I [] in MCFileTreeRepository(MCFileBasedRepository)>versionReaderForFileNamed:do: 0x4896708: a(n) MCFileTreeRepository 0xbff6cfe4 M MCFileTreeRepository>readStreamForFileNamed:do: 0x4896708: a(n) MCFileTreeRepository 0xbff6d00c I MCFileTreeRepository(MCFileBasedRepository)>versionReaderForFileNamed:do: 0x4896708: a(n) MCFileTreeRepository 0xbff6d02c M MCFileTreeRepository(MCFileBasedRepository)>loadVersionFromFileNamed: 0x4896708: a(n) MCFileTreeRepository 0xbff6bddc M [] in MCFileTreeRepository>goferVersionFrom: 0x4896708: a(n) MCFileTreeRepository 0xbff6be0c M Array(SequenceableCollection)>collect: 0x1df4d50: a(n) Array 0xbff6be28 M MCFileTreeRepository>goferVersionFrom: 0x4896708: a(n) MCFileTreeRepository 0xbff6be4c I MetacelloCachingGoferResolvedReference(GoferResolvedReference)>version 0x1df4c80: a(n) MetacelloCachingGoferResolvedReference 0xbff6be64 M MetacelloCachingGoferResolvedReference>version 0x1df4c80: a(n) MetacelloCachingGoferResolvedReference 0xbff6be7c M [] in MetacelloFetchingMCSpecLoader>resolveDependencies:nearest:into: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff6be9c M OrderedCollection>do: 0x1df4de8: a(n) OrderedCollection 0xbff6bec8 M [] in MetacelloFetchingMCSpecLoader>resolveDependencies:nearest:into: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff6bee4 M BlockClosure>on:do: 0x1df4e98: a(n) BlockClosure 0xbff6bf0c M MetacelloFetchingMCSpecLoader>resolveDependencies:nearest:into: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff6bf4c M [] in MetacelloFetchingMCSpecLoader>linearLoadPackageSpec:gofer: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff6bf68 M [] in MetacelloSqueakPlatform>do:displaying: 0x4067c78: a(n) MetacelloSqueakPlatform 0xbff6bf90 M [] in MorphicUIManager>displayProgress:at:from:to:during: 0x277f388: a(n) MorphicUIManager 0xbff6bfac M BlockClosure>on:do: 0x1df5078: a(n) BlockClosure 0xbff6bfd8 M [] in MorphicUIManager>displayProgress:at:from:to:during: 0x277f388: a(n) MorphicUIManager 0xbff6bff8 M BlockClosure>ensure: 0x1df5170: a(n) BlockClosure 0xbff6c01c M MorphicUIManager>displayProgress:at:from:to:during: 0x277f388: a(n) MorphicUIManager 0xbff5dca0 M ProgressInitiationException>defaultResumeValue 0x1df4280: a(n) ProgressInitiationException 0xbff5dcbc M ProgressInitiationException(Exception)>resume 0x1df4280: a(n) ProgressInitiationException 0xbff5dcd4 M ProgressInitiationException>defaultAction 0x1df4280: a(n) ProgressInitiationException 0xbff5dcf0 M UndefinedObject>handleSignal: 0x2375b00: a(n) UndefinedObject 0xbff5dd14 M MethodContext(ContextPart)>handleSignal: 0x4897410: a(n) MethodContext 0xbff5dd38 M MethodContext(ContextPart)>handleSignal: 0x45468a8: a(n) MethodContext 0xbff5dd5c M MethodContext(ContextPart)>handleSignal: 0x490d428: a(n) MethodContext 0xbff5dd80 M MethodContext(ContextPart)>handleSignal: 0x490d488: a(n) MethodContext 0xbff5dda4 M MethodContext(ContextPart)>handleSignal: 0x490d4e8: a(n) MethodContext 0xbff5ddc8 M MethodContext(ContextPart)>handleSignal: 0x490d548: a(n) MethodContext 0xbff5ddec M MethodContext(ContextPart)>handleSignal: 0x490d5a8: a(n) MethodContext 0xbff5de10 M MethodContext(ContextPart)>handleSignal: 0x490d608: a(n) MethodContext 0xbff5de34 M MethodContext(ContextPart)>handleSignal: 0x490d668: a(n) MethodContext 0xbff5de58 M MethodContext(ContextPart)>handleSignal: 0x490d6c8: a(n) MethodContext 0xbff5de74 M ProgressInitiationException(Exception)>signal 0x1df4280: a(n) ProgressInitiationException 0xbff5de8c M ProgressInitiationException>display:at:from:to:during: 0x1df4280: a(n) ProgressInitiationException 0xbff5deb8 M ProgressInitiationException class>display:at:from:to:during: 0x2862fd8: a(n) ProgressInitiationException class 0xbff5dee4 M ByteString(String)>displayProgressAt:from:to:during: 0x1df3898: a(n) ByteString 0xbff5df0c M MetacelloSqueakPlatform>do:displaying: 0x4067c78: a(n) MetacelloSqueakPlatform 0xbff5df2c M MetacelloFetchingMCSpecLoader>linearLoadPackageSpec:gofer: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff5df4c M MetacelloPackageSpec>loadUsing:gofer: 0x48d11a0: a(n) MetacelloPackageSpec 0xbff5df70 M [] in MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>linearLoadPackageSpecs:repositories: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff5df90 M OrderedCollection>do: 0x490d918: a(n) OrderedCollection 0xbff5dfb0 M MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>linearLoadPackageSpecs:repositories: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff5dfe0 I [] in MetacelloFetchingMCSpecLoader>linearLoadPackageSpecs:repositories: 0x48ced80: a(n) MetacelloFetchingMCSpecLoader 0xbff5e000 M BlockClosure>ensure: 0x490d9a8: a(n) BlockClosure 0xbff5e028 I MetacelloLoaderPolicy>pushLoadDirective:during: 0x48b59c8: a(n) MetacelloLoaderPolicy 0x490da58 w MetacelloLoaderPolicy>pushLinearLoadDirectivesDuring:for: ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/272

3 4

Compiling the windows 32 bits vm
by Cyril Ferlicot D 12 Jul '18

12 Jul '18

Hello, I am trying to compile my first vm, so I read the README and HowToBuild on OpenSmalltalk git repository. I tried to build the build.win32x86/pharo.cog.spur flavour on Windows 7 after installing cygwin with this command: setup-x86.exe -dgnqNO -R "E:\cygwin" -s "http://cygwin.mirror.constant.com" -l "E:\cygwin\var\cache\setup" -P mingw64-i686-gcc-core,mingw64-i686-gcc-g++,mingw64-i686-headers,mingw64-i686-runtime,zip,mingw64-i686-clang,mingw64-i686-openssl,libiconv-devel,libglib2.0-devel,perl,mingw64-i686-zlib,make,cmake,wget,mingw64-i686-win-iconv The build fail with this error: config.status: creating config.h.win32 config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands configure: WARNING: cache variable lt_cv_path_LD contains a newline make[2]: Entering directory '/cygdrive/e/cog/oscogvm/build.win32x86/pharo.cog.spur/builddbg/third-party/pkg-config-0.29.1' Makefile:311: *** missing separator. Stop. make[2]: Leaving directory '/cygdrive/e/cog/oscogvm/build.win32x86/pharo.cog.spur/builddbg/third-party/pkg-config-0.29.1' make[1]: *** [../third-party/Makefile.pkgconfig:26: /cygdrive/e/cog/oscogvm/.thirdparty-cache/windows/i386/bin/pkg-config.exe] Error 2 make[1]: Leaving directory '/cygdrive/e/cog/oscogvm/build.win32x86/pharo.cog.spur' make: *** [../common/Makefile:157: debug] Error 2 I have to say that I have really few experience with everything around the vm and maybe this is a problem easy to solve. But not with my knowledge. Does anyone has an idea of what might be the problem? Also, I'm not sure it is the right place for this kind of questions since it's vm-dev and this is a vm usage question. So, is it the right ML or is there another one? -- Cyril Ferlicot https://ferlicot.fr

7 20

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev July 2018