2018-03-07 23:07 GMT-03:00 Ben Coman <b...@openinworld.com>:
> On 8 March 2018 at 02:38, Michael Forster <m...@forsterfamily.ca> wrote:
>> On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <b...@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
>> 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 <git...@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.
"system library" means it's pre-installed in some Linux distros?
I installed a Debian 4.9.65-3+deb9u1 (2017-12-23) last week and
libsodium is not present.
I use Windows and also isn't available by default.
In any case, how do you ensure libsodium system lib matches your interface code?
What do you do now if target has a different version?
> 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.
That would be really cool