[update: I just updated the title of the post, because on other Linux machines, like our test and production servers, there is a link named libcrypto.so in the 64 bits libraries path, so the change to the ini file is not necessary there…
20591215 0 lrwxrwxrwx 1 root root 16 Jun 20 13:29 /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
My dilemma these days is that I have very little time besides my work on Kontolino. At the sime time, I’d like to re-start blogging and hopefully provide some helpful information to the Smalltalk world. So all I can do at this moment is use my blog as a little notebook of findings that I feel will either be helpful to myself in the future or – even better – to others as well.
We’re currently attempting to port or Application from 32 to 64 bits. so far, the process was quite smooth on our development environment (Windows), but needs a little tweaking on Linux.
First, let me say something so surprisingly positive that I could hardly believe it: we are using an external library on Linux which is available in a 32 bit as well as a 64 bit variant. And what can I say: our code needed absolutely no change! It just ran on 64 bits in both Windows and Linux. Fantastic!
Some other things I found so far:
- With Environments, you can easily have 32 bits and 64 bit versions of VAST coexist on one machine, both on Windows and Linux. I don’t know if I ever mentioned it, but Environments is an excellent addition to VA Smalltalk!!!
- You must not mix .ini files between 32 and 64 bit images. This can lead to strange effects. As a long time VA Smalltalker, I should of course know that. I just keep forgetting it.
- On my play/test machine for dirty experiments, a used Dell Laptop with Xubuntu 18.04 on it, I had a strange effect with Seaside: The session object would be nil and never be initialized, even though all seemed well. The error messages were somewhat useless for finding the problem. It turned out that trying to visit http://localhost:800 shows a much more helpful error message: WANoSecureKeyGeneratorAvailable.
The strange thing here is that the 32 bit version of the same app is running on that machine quite nicely. So I was sure this must be a library problem.
And it is: there is a libcrypto.so in /usr/lib/i386-linux-gnu/, but obviously there is no 64 bit version of it on my machine. I checked that openssl (without :i386) is installed.
But there is /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 on the machine. So at least on this machine I have to change the CRYPTO_LIB parameter to point to /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 or set a link to it. Now the session runs perfectly.
The process is not finished yet, so there may be new findings over the next few days. For now, I’ll stop here…