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.
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.
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: