Getting The New Squeak 5 to Run on 64 Bit Linux

Getting the new Squeak 5 to run on 64 bit Linux

You already got all information you need:

You may need to (re)install the 32-bit libraries.

Squeak 5 is currently 32bit only. Hence, you need 32bit libraries.
It cannot use your 64bit libraries.

You may need thes:e packages (I use Debian/Ubuntu names, CentOS/RH/SuSE should be similar):

• libc6:i386
• libuuid1:i386
• libkrb5-3:i386
• libk5crypto3:i386
• zlib1g:i386
• libcomerr2:i386
• libkrb5support0:i386
• libkeyutils1:i386
• libx11-6:i386
• libgl1-mesa-glx:i386
• libsm6:i386
• libssl1.0.0:i386

(note the :i386 in the names)

Squeak SMTPs on Linux

The version of the SqueakSSL plugin you are using is compiled against OpenSSL, which in turn required clock_gettime.

Note the that the manpage says

 Link with -lrt (only for glibc versions before 2.17).

Apparently, your SqueakSSL binary was compiled on a system later than glibc 2.17.

Here are some options:

1. Try the SqueakSSL binary from https://github.com/squeak-smalltalk/squeakssl/releases which are statically linked against LibreSSL. Note: They might be some weeks out of date.
2. See whether you could use an updated Linux version with glibc >= 2.17

3. Try something like re-linking or pre-loading (see How to relink existing shared library with extra object file), for example

   LD_PRELOAD=/usr/lib32/librt.so /path/to/squeak


We hope to sort this out soon-ish. Maybe you want to open an issue at https://github.com/OpenSmalltalk/

Is there any Smalltalk VM and/or Image which supports 64-bit?

There is and old 64 bit image and vm for squeak. At Esug I've pushed to get 64 bit support for Pharo going, but that's moving forward slowly. [edit] And I see there is now an experimental 64-bit squeak vm and image for linux x86. [/edit] The squeak vm was a pre-cog one. Eliot Miranda is working on a new bytecode set/image format for 64 bits. Once that's finished, I'd assume Pharo, Squeak and Newspeak will migrate to that.

A 64 bit image might run slower than a 32 bit one, but that is probably by nearly a constant factor, and therefore getting less and less relevant as computer speed keeps growing. More important is that being able to use large amounts of ram allows the developer to make time-space tradeoffs. That is, between his time and the cost of ram. 4GB costs less than an hour of engineering time in Western Europe and the US.

When using the larger immediate objects (smallints up to 2^62/63, smallfloats?) the 64 bit images can be faster. Gemstone has collection implementations that scale a lot better, the original implementations use a single array as backing store. For large collections you need at least array of array as backing store.

I've done some data conversions where I'd strongly prefer to load all data in the image and then start analysing, transforming, cleaning, and exporting it. Working from disk slows the process down by a factor of 100. That reduces feedback cycles from minutes to hours or days. The feedback cycle is crucial, especially when starting the process, as I don't know enough about the system by then. Later in the process I might be able to partition it, but that assumes knowledge that simply isn't there.

Squeak Win 7 Error: No content to install

It seems that when an ImageFile is specified in Squeak.ini (as is the case in Squeak-4.2-All-in-One) that image file is always used. And if you pass a file as an argument to Squeak.exe (or drag and drop it) that file is passed to the image as a source file to be executed instead.

If you want to open an image file by dropping it on the Squeak.exe icon remove the ImageFile directive from Squeak.ini

SqueakMap won't work in a fresh 3.10 dev image

This fixes it:

SMSqueakMap default loadUpdates

Easy, huh?

---

Related Topics