[Ring] Ring daemon compile error
Hi all, I am trying to compile ring daemon from source code(ring-daemon beta2) on Ubuntu 16.04 following the instruction from https://docs.ring.cx/dev/compiling_and_installing/daemon.html It works well first, but when it comes to the ring-daemon/bin/ directory, error turns out like this make[3]: Entering directory '/home/houmin/ring-daemon/bin' CXXLDdring ../src/.libs/libring.so: undefined reference to `nettle_gcm_set_key' ../src/.libs/libring.so: undefined reference to `nettle_gcm_aes_set_iv' ../src/.libs/libring.so: undefined reference to `nettle_curve25519_mul' ../src/.libs/libring.so: undefined reference to `nettle_aes192_encrypt' ../src/.libs/libring.so: undefined reference to `nettle_des3_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_des3_encrypt' ../src/.libs/libring.so: undefined reference to `nettle_base64_decode_update' ../src/.libs/libring.so: undefined reference to `nettle_dsa_signature_init' ../src/.libs/libring.so: undefined reference to `nettle_secp_256r1' ../src/.libs/libring.so: undefined reference to `idna_to_unicode_8z8z' ../src/.libs/libring.so: undefined reference to `nettle_gcm_update' ../src/.libs/libring.so: undefined reference to `nettle_yarrow256_update' ../src/.libs/libring.so: undefined reference to `nettle_mpz_sizeinbase_256_u' ../src/.libs/libring.so: undefined reference to `nettle_arctwo40_set_key' ../src/.libs/libring.so: undefined reference to `nettle_rsa_encrypt' ../src/.libs/libring.so: undefined reference to `nettle_hmac_md5_digest' ../src/.libs/libring.so: undefined reference to `nettle_md2_update' ../src/.libs/libring.so: undefined reference to `nettle_aes128_set_encrypt_key' ../src/.libs/libring.so: undefined reference to `nettle_memxor'I ../src/.libs/libring.so: undefined reference to `nettle_aes256_set_decrypt_key' ../src/.libs/libring.so: undefined reference to `nettle_rsa_public_key_prepare' ../src/.libs/libring.so: undefined reference to `nettle_gcm_aes_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_sha3_384_digest' ../src/.libs/libring.so: undefined reference to `nettle_dsa_generate_params' ../src/.libs/libring.so: undefined reference to `nettle_base64_decode_init' ../src/.libs/libring.so: undefined reference to `nettle_des_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_ccm_encrypt_message' ../src/.libs/libring.so: undefined reference to `nettle_rsa_public_key_clear' ../src/.libs/libring.so: undefined reference to `nettle_sha3_512_digest' ../src/.libs/libring.so: undefined reference to `nettle_umac128_set_key' ../src/.libs/libring.so: undefined reference to `nettle_arcfour_crypt' ../src/.libs/libring.so: undefined reference to `nettle_gcm_camellia256_update' ../src/.libs/libring.so: undefined reference to `nettle_ecdsa_verify' ../src/.libs/libring.so: undefined reference to `nettle_umac96_set_key' ../src/.libs/libring.so: undefined reference to `nettle_hmac_md5_set_key' ../src/.libs/libring.so: undefined reference to `nettle_gcm_camellia128_update' ../src/.libs/libring.so: undefined reference to `nettle_hmac_sha512_digest' ../src/.libs/libring.so: undefined reference to `gnutls_x509_crl_set_version' ../src/.libs/libring.so: undefined reference to `nettle_aes192_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_yarrow256_slow_reseed' ../src/.libs/libring.so: undefined reference to `nettle_umac96_set_nonce' ../src/.libs/libring.so: undefined reference to `nettle_sha1_init' ../src/.libs/libring.so: undefined reference to `nettle_gcm_aes_set_key' ../src/.libs/libring.so: undefined reference to `nettle_aes128_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_sha3_256_init' ../src/.libs/libring.so: undefined reference to `nettle_sha1_update' ../src/.libs/libring.so: undefined reference to `nettle_salsa20_set_key' ../src/.libs/libring.so: undefined reference to `idna_to_ascii_8z' ../src/.libs/libring.so: undefined reference to `nettle_secp_521r1' ../src/.libs/libring.so: undefined reference to `nettle_ecc_point_mul' ../src/.libs/libring.so: undefined reference to `gnutls_x509_crl_set_number' ../src/.libs/libring.so: undefined reference to `nettle_arctwo_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_hmac_sha256_digest' ../src/.libs/libring.so: undefined reference to `nettle_gcm_set_iv' ../src/.libs/libring.so: undefined reference to `nettle_cbc_decrypt' ../src/.libs/libring.so: undefined reference to `nettle_hmac_sha1_set_key' ../src/.libs/libring.so: undefined reference to `nettle_ecc_size' ../src/.libs/libring.so: undefined reference to `nettle_aes256_encrypt' ../src/.libs/libring.so: undefined reference to `nettle_md2_init' ../src/.libs/libring.so: undefined reference to `nettle_yarrow256_random' ../src/.libs/libring.so: undefined reference to `nettle_salsa20_crypt' ../src/.libs/libring.so: undefined reference to `nettle_gcm_camellia128_set_iv' ../src/.libs/libring.so: undefined reference to `nettle_gcm_camellia256_digest' ../src/.libs/libring.so:
Re: [Ring] Future of platform-specific clients?
There's a larger point in the discussion about plaform-specific clients, which is the distinction between a protocol specification and an implementation. As I look at the ring.cx site, it talks about the implementation. It does not clearly give a oprotocol spec (something like you'd find in IETF), so that someone could write an independent interoperable implementation. Successful protocols are either proprietary walled gardens or have multiple independent implementations. SIP and ZRTP, for example, are the multiple implementation type. If I'm following correctly, ring is opendht for discovery (which would then have to be examined for protocol vs defined by a singleton implementation), something sip-like for bringing up a session with the peer once you find it, probably some kind of STUN/TURN to deal with NAT, and something RTP/ZRTP-ish to transport the bits.
Re: [Ring] Future of platform-specific clients?
Please integrate GNU Ring with CardBook: https://addons.mozilla.org/thunderbird/addon/cardbook/ It is based on the vCard format and runs on multiple operating systems (Linux, Windows, Mac, BSD, ...) The developer of CardBook is Philippe Vigneau who can be emailed at: cardbook.thunderb...@gmail.com Thank you On 22/06/17 06:07, Anthony Léonard wrote: Hi Adonay, Last but not less important: I might be wrong on the following: One of the issues of using JavaScript might be the loss of integration with, for example, vCard contact managers. But of course it's always better to ask a real expert instead of an occasional user and contributor (this is me). :) You are half-right (or wrong, depends on your mood :) ). The integration with third party contact managers (like GNOME Contacts on GNU/Linux or Contacts app on MacOS) is currently managed by the client layer on each platforms. The client "injects" contacts it gather from external applications in its own contact list alongside the contacts coming internally from the daemon. The part on which you're wrong is that the loss of integration is not related to JS itself but to the fact that an interface between a new “ring-electron” client and contact managers is yet to be implemented. It is not infeasible but requires making a wrapper in C/C++ for every existing "contact-APIs" to expose those interfaces to JS code. Another solution could be to integrate this support inside the daemon, but also requires coding interfaces for each contact systems as those interfaces are currently split between every clients. Best regards. Anthony L.
