The issue is/was that we did not have -lgnutls in the linker. At least
that is my guess.
We are currently conflating two things here: one is that libgcrypt(!)
was not detected. This is due to a change in the m4 detection logic. I
fixed that some releases ago already.
The other, newer, issue since 0.22.0 is that the linker needs us to
provide -lgnutls (at least that is my working assumption).
For some reasons most/our build systems and their linker allow
transitive resolution of linking dependencies, but in case of Arch the
linker errors out.
So if I am correct git master or the patch I provided in the other post
should fix this.
BR
On 11.10.24 12:43, Christian Grothoff wrote:
Gnutls people are also surprised (no intentional/expected breakage),
they ask:
>>>
Hello Christian, my random guess is that gnutls.pc is somehow corrupted
and doesn't list necessary libraries. Would it be possible to ask the
reporter to try again with make V=1?
<<<
Can you please do that and report back?
Thanks!
-Christian
On 10/11/24 03:53, madmurphy wrote:
Hi folks, I hope you are doing well! People on AUR are complaining
<https://aur.archlinux.org/packages/gnunet#comment-993046> that the
new versions of GNUTLS (3.8.7) and GNUnet (0.22.x) don't work well
together. And I can confirm that I have been being unable to compile
GNUnet for about a week now. The problem appears with both GNUnet
0.22.0 and 0.22.1, but I currently have GNUnet 0.22.0 installed, which
means that a few months ago everything worked well. And in turn this
means that either the last update of libcurl-gnutls
<https://archlinux.org/packages/core/x86_64/libcurl-gnutls/> (Sept.
18, 2024, 11:22 a.m. UTC → 8.10.1) or the last update of gnutls
<https://archlinux.org/packages/core/x86_64/gnutls/> (Aug. 16, 2024,
11:25 a.m. UTC → 3.8.7) broke it.
Is any of you dealing with the same version numbers in GNUnet's
dependencies?
--madmurphy
