Wow. Great stuff. Thank you very much. I'm sure with this we can find a 
solution. I mean Squeak and Pharo. I started the Pharo 1.4 all-in-one in 
Visualbox using a Linux image and the same six tests fail after loading 
with ConfigurationOfXtreams.

In CentoOS 5.3 in Visualbox "ldconfig -p | grep libcrypto" produced:

     libcrypto.so.10 (libc6) => /usr/lib/libcrypto.10

If I read your email right, then the problem shouldn't be too hard to 
fix. Of course, this has been a great week for me being wrong.

When I read:

(BTW, XTHMAC is a keyed-hash construct not something specific to Macs)


I laughed out loud. That's at least the third time this week I've been 
completely wrong. I got an email from Tony Garnock Jones this morning 
about a post I made about Altitude on Monday, which was completely of 
the mark. I had to tell him I was just out-to-lunch and had been set 
straight by Colin Putney, who made it clear in no uncertain terms I was 
making no sense.

It's a small price to pay, though, to get such valuable assistance in 
debugging a part of Xtreams, which I am confident will be of great use 
to the entire open source Smalltalk community.

Thank you,

Chris


Loved the Morse code example in the ESUG 2010 video, BTW. Lots of fun.


On 12-07-26 11:04 PM, mkobetic at gmail.com wrote:
> I'd love to have a better answer, but this is the joy of relying on third party delivered external libraries. The Xtreams code is looking for library 'libcrypto.so' (without any version numbers attached). On some systems it will be found on others it won't. The quickest test at the smalltalk level is
>
> 	XTLibCrypto versionString
>
> If it returns a version string the library is found fine. If not then you get the module not found error. The best way to see what's available at the OS level is running something like:
>
> 	ldconfig -p | grep libcrypto
>
> If it shows one that's called just 'libcrypto.so' and it is the right architecture (libc6) vs (libc6, x86-64) then it should work. If you have a system which only sees libs with the version numbers then you need to create an "unversioned" symlink somewhere in the loader path (LD_LIBRARY_PATH). What I usually do is add a file to /etc/ld.so.conf.d/ that lists directories where I maintain my own symlinks.
>
> Alternatively, you can probably modify the Smalltalk code to reference the version number as well, but that can be cumbersome. The difficulty with that approach is that the version number changes inconveniently often. These days you can easily encounter 0.9.7, 0.9.8, or one of the 1.0.0 flavors and 1.1.0 is coming out soon. Moreover the Xtreams code will work with any of those (the newer versions may provide more algorithms or capabilities, but that's not available in the squeak port yet).
>
> It's been a while since I played with these in Squeak/Pharo, but I also had difficulties with various Squeak/Pharo and VM combinations that I didn't have time to narrow down. So sometimes trying different VMs showed different results too. Unfortunately I don't have anything more specific than that.
>
> In VW we've recently implemented a more flexible mechanism for the selection of the implementation back-end which allows falling back to other implementations if the preferred one fails (e.g. a plain smalltalk implementation, or in Squeak it could be a plugin based one). The streams really don't care how the algorithm is actually implemented as long as the XTHash and XTHMAC APIs are functioning (BTW, XTHMAC is a keyed-hash construct not something specific to Macs). This sort of mechanism can provide a bit more user friendly experience, although it can hide the fact that you're falling back to something else when that may not be what you want. Pick your poison :-).
>
> HTH,
>
> Martin
>
>