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