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 > [...] > > > 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 <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. 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.