(no subject)

Page 1.0 of 1.2
  • David Sugar
    David Sugar
    2012-12-05

    I had just gone through two weeks of hell getting gnutls to work in ucommon again and back as the default, and actually while I am very pleased with the results of that, it is something else I did not receive any help, participation, or interest from anyone else in either. Ultimately I would love to consolidate all our crypto functions into ucommon, which already addresses these library dependency issues much better, but I don't expect to see anyone help with that either...

    In regard to zrtp specifically, gcrypt fell out of favor because it did not a the time support elliptic curve algorithms, and gnutls does not expose these either as a front end, even if gcrypt (or more correctly, nettle) may now have them, where-as openssl does.

    Newer versions of libzrtp have a cmake build option to build it as "standalone" library without using any crypto library depenedency with the newer enable-crypt_standalone=true cmake option. All necessary sources are included. Ideally, again, all this should be merged into ucommon's -lusecure instead.

    I would love to see a patch or participation on how we can change and improve our code. I just don't see it happening.

     
  • I'm sorry if I came across as critical of your efforts. As I am pretty uninformed when it comes to cryptography (not to mention telephony), I wasn't aware of the relative capabilities of the various packages. For my part, I'm just trying to keep all GNU packages building smoothly with GSRC and I ran into these problems with libzrtp. With many build problems, I can patch them pretty easily; in this case, I quickly understood that I was in over my head, which is why I came here.

    I'll give that CMake option a try to see if it will resolve this problem. I'll also try to look into CMake in general to figure out why it wasn't finding OpenSSL on my system; if I find something, I'll provide a patch.

     
  • Well, I've resolved it for now. The problem is that CMake seems to ignore some important environment variables, PKG_CONFIG_PATH in this case; it looks like it will only look for pkg-config files under the same prefix as PKG_CONFIG_EXECUTABLE. Since GSRC was trying to use its own non-standard pkg-config location, it couldn't find OpenSSL installed in the usual system location. I've resolved for now by forcing it to use the system pkg-config.

     
    • David Sugar
      David Sugar
      2012-12-07

      I am sorry, it has just been a particularly rough few weeks, and I am glad we do have this effort with GSRC. Werner actually choose to stop maintaining/pull automake support awhile back in favor of just supporting cmake, and actually I had been thinking about re-introducing automake in it again. There are some great aspects of cmake, and it is certainly much simpler to maintain, but, like this, also a number of subtle places where it produces interesting surprises. I think this is the only (that is within GNU) package I maintain which at present only uses cmake, and I have no plans to change that for any of the other ones.

      I think you actually also can manually insert the pkg config path in cmake using the ENV support inside the cmake scripting itself (or for example using a toolchain file to force create an initial environment value inside cmake), but yes, it likely strips the one set in the inherited environment it receives.

       
    • David Sugar
      David Sugar
      2012-12-07

      Actually, it looks like, for my debian hosted mingw32 build tree that is exactly what I do; I preload PKG_CONFIG_PATH through a cmake toolchain file, for example, like:

      set(ENV{PKG_CONFIG_LIBDIR} "${FRAMEWORKS_PREFIX}/lib/pkgconfig")
      set(ENV{PKG_CONFIG_PATH} "${FRAMEWORKS_PREFIX}/lib/pkgconfig")