configure: fix usage of libgpg-error with --with-local-libgcrypt

[IvanNardi]

Right now, using external libgcrypt, nDPI is not linked to libgpg-error
because configure script never checks for it.

ivan@ivan-Latitude-E6540:~/svnrepos/nDPI(dev)$ CC=gcc-11 CXX=g++-11 CFLAGS="-O3 -g -Werror" ./autogen.sh --enable-debug-messages --with-pcre  --with-local-libgcrypt && make -s -j
[...]
checking for numa_available in -lnuma... yes
checking for pcap_open_live in -lpcap... yes
checking for pthread_setaffinity_np in -lpthread... yes
checking for gcry_cipher_checktag in -lgcrypt... yes             <------- missing check for libgpg-error
checking for pcre_compile in -lpcre... yes
checking that generated files are newer than configure... done
[...]
ivan@ivan-Latitude-E6540:~/svnrepos/nDPI(dev)$ grep HAVE_LIBGPG_ERROR src/include/ndpi_config.h
/* #undef HAVE_LIBGPG_ERROR */

Make both libgcrypt and libgpg-error mandatory if
--with-local-libgcrypt is used.

Technically speaking, libgpg-error might be optional, because it is used
only for debug messages. However having both libraries mandatory
slightly simplified the logic.
In most environments, libgpg-error is a dependency of libgcrypt anyway,
so having both libraries should be the standard case.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[IvanNardi]

@lnslbrty , could you take a look, please? The patch works, but I don't know if that is the best way to fix the issue.

[utoni]

Your PR will work fine.
I am a bit concerned about package maintainers, because some distros do not like explicit linking an executable to a shared object which does not use any symbols of it. That could be (under certain circumstances) the case here or am I wrong?

[IvanNardi]

That could be (under certain circumstances) the case here or am I wrong?

That's definitely the case here: libgpg-error is used only if DEBUG_CRYPT is defined.

I could rework QUIC logs to get rid of DEBUG_CRYPT and QUIC_DEBUG defines and to use "standard" log mechanics and check for --enable-debug-messages in configure scripts before checking for libgpg-error...

But, please note that right now libgpg-error is linked from ndpiReader anyway, probably because on my environment (Ubuntu) libgpg-error is a dependency of libgcrypt, i.e. ndpiReader links a library without using any symbol of it

ivan@ivan-Latitude-E6540:~/svnrepos/nDPI(dev)$ CC=gcc-11 CXX=g++-11 CFLAGS="-O3 -g -Werror" ./autogen.sh --enable-debug-messages --with-pcre  --with-local-libgcrypt && make -s -j
[...]
ivan@ivan-Latitude-E6540:~/svnrepos/nDPI(dev)$ ldd example/ndpiReader
	linux-vdso.so.1 (0x00007fffa7585000)
	libpcap.so.0.8 => /lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f42be8fd000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f42be7df000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f42be690000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f42be61d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f42be5fa000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f42be408000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f42be3e3000)  <---------------
	/lib64/ld-linux-x86-64.so.2 (0x00007f42beba7000)

My original message is a bit confusing, sorry. The issue is not that libgpg-error is not linked; the issue is that libgpg-error functions are not used because HAVE_LIBGPG_ERROR is not defined.

[IvanNardi]

Ok.
I'll update the QUIC logs anyway in the next future