On 8 March 2018 at 02:38, Michael Forster <mike@forsterfamily.ca> wrote:
On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <btc@openinworld.com> wrote:
[...]
>
> If that is the one available from the Pharo Catalog, when I tried it, it
> used a different api than the libsodium library supplied by Ubuntu 16.04.
>
> It makes this call out...
>�� �� crypto_hash_sha512_ref()
> but Ubuntu libsodium library did not export that, but instead...
>�� ��crypto_hash_sha512()
>
> I failed to track down the implications of the "_ref",
> and at that time Crypto-Nacl did not supply a 64-bit library,
> so a single FFI matching the system supplied libsodium library was easier.
> Also as a minor policy, I prefer to use the system library than one compiled
> by a third-party.
>
> cheers -ben
[...]


Hi,

Yes, I recommend using the OS/package-manager supplied libsodium
(based on https://github.com/jedisct1/libsodium). The downloads
provided on Tony's site were based on early commits that exported the
"_ref" functions instead:

�� �� commit e144f9d40d5695b69306bde729d6d8adcd62b1c4
�� �� Author: Frank Denis <github@pureftpd.org>
�� �� Date:�� ��Mon Apr 22 16:30:31 2013 -0700

�� �� �� �� crypto_hash_sha(256|512) are the exported functions that have
to be exported.
�� �� �� �� _ref are implementations, that shouldn't be exported.

Thanks for clarifying that.

��

To be useful, http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl/ should be
updated to use a system-supplied libsodium.

Or at least to the later api.�� �� In general there is some advantage in packaging the C-lib with the Smalltalk package
for people experimenting with it the first time, to ensure the function prototypes match.�� But flipping into production
may prefer the system library. Currently it seems awkward to switch later��to a system library since the library used is hard coded.����
How do others work around that?

Perhaps it would be good to have the external library initialized into an instance variable of FFILIbrary,��
so a user-application can change��the external C-library used without changing code in someone else's ffi-interface package.

cheers -ben

P.S. On the dream list would be a GUI for managing referenced��external��C-libraries, including browsing their exported functions.��