Re: GNUnet and GNUTLS

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