Re: About GNUrl and cURL

[madmurphy]

I tried again, just to be sure. Still get

...
HTTP Client:curl (OpenSSL)
...

My config.log attached.

--madmurphy

On Wed, Sep 7, 2022 at 8:17 PM Martin Schanzenbach 
wrote:

> I am quite sure it works now as expected so you would need to provide me
> with the config.log to debug.
> Maybe your link now points to the "Normal" curl because of the testing?
>
> Excerpts from madmurphy's message of 2022-09-07 18:55:19 +0100:
> > I now commited a programmatic check for GnuTLS. Try it out. It should not
> > require your fix.
> >
> > Mmm without my trick the configure script still prints
> >
> > ...
> > HTTP Client:curl (OpenSSL)
> > ...
> >
> > --madmurphy
> >
> > On Wed, Sep 7, 2022 at 3:44 PM Schanzenbach, Martin <
> mschanzenb...@posteo.de>
> > wrote:
> >
> > >
> > >
> > > > On 7. Sep 2022, at 14:59, madmurphy  wrote:
> > > >
> > > > Hi Martin,
> > > >
> > > > That means, if you can find out how the packages linked against
> > > libcurl-compat or libcurl-gnutls are built from source, you can do the
> same
> > > with the gnunet package.
> > > > The packages in the official repositories that explicitly require
> > > libcurl-gnutls (and not simply libcurl) are spotify-launcher (PKGBUILD
> /
> > > package source code) and steam-native-runtime (PKGBUILD / no source
> code
> > > here, it's just glue). But it is a mystery to me how they would find
> out.
> > >
> > > They probably do not distinguish between the two versions. The package
> > > build simply makes sure that during linking, the correct link is set.
> > >
> > > >
> > > > Ah look here:
> > >
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > > The curl-compat package does link libcurl.so against the versioned
> files.
> > > > And curl-gnutls does the same:
> > >
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > > That libcurl-compat package compiles curl with different build
> settings,
> > > then renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally
> links
> > > libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0,
> > > libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0,
> > > libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old
> > > versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0
> > > remain linked to the binary shipped by the original curl package).
> > > >
> > > > That libcurl-gnutls package does exactly the same, but the basename
> of
> > > the symlinks becomes libcurl-gnutls.so.* instead of simply
> libcurl.so.*.
> > > >
> > > > FYI I updated the detection logic again. You may check if that works
> for
> > > you know.
> > > > If I try to build the last GNUnet commit with libcurl-gnutls from the
> > > official Arch repository I still get
> > > >
> > > > ...
> > > > HTTP Client:curl (OpenSSL)
> > > > ...
> > > >
> > > > while if I use my hacked libcurl-gnutls I get
> > > >
> > > > ...
> > > > HTTP Client:curl-gnutls
> > > > ...
> > > >
> > > > I think I found a solution. I will publish a glue package on AUR
> named
> > > libcurl-gnutls.so, which will depend on the official libcurl-gnutls,
> and on
> > > which GNUnet will depend. All this glue package will do is simply
> creating
> > > an unversioned symlink.
> > >
> > > Yeah.. curl-config just seems to be a bash script where the supported
> > > backends are hardcoded when it is "compiled".
> > > So even if you install curl-gnutls it will still say "openssl"...
> great.
> > >
> > > I now commited a programmatic check for GnuTLS. Try it out. It should
> not
> > > require your fix.
> > > No idea if anybody actually ships curl with multiple TLS backends, but
> we
> > > check on runtime anyway so its fine.
> > > We may want to set the backend explicity maybe with
> curl_global_sslset...
> > >
> > > BR
> > > Martin
> > >
> > > >
> > > > --madmurphy
> > > >
> > > >
> > > > On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach <
> > > mschanzenb...@posteo.de> wrote:
> > > > FYI I updated the detection logic again. You may check if that works
> for
> > > > you know.
> > > > Know that even if it detected "curl-openssl" for you the last time,
> it
> > > > probably was correctly linked against the "drop-in" libcurl-gnutls.
> > > > We just were not able to detect that.
> > > >
> > > > BR
> > > >
> > > > Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52
> +:
> > > > > Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > > > > > Okay, about the libcurl-gnutls package, Martin was right. If I
> add
> > > this
> > > > > > line to the PKGBUILD of that package,
> > > > > >
> > > > > > ln -s libcurl-gnutls.so.4.8.0
> "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > > > > >
> > > > > > Everything goes well in GNUnet and the configure script prints
> > > > > >
> > > > > > ...
> > > > > > HTTP Client:curl-gnutls
> > > > > > ...
> 

Re: About GNUrl and cURL

[Martin Schanzenbach]

I am quite sure it works now as expected so you would need to provide me
with the config.log to debug.
Maybe your link now points to the "Normal" curl because of the testing?

Excerpts from madmurphy's message of 2022-09-07 18:55:19 +0100:
> I now commited a programmatic check for GnuTLS. Try it out. It should not
> require your fix.
> 
> Mmm without my trick the configure script still prints
> 
> ...
> HTTP Client:curl (OpenSSL)
> ...
> 
> --madmurphy
> 
> On Wed, Sep 7, 2022 at 3:44 PM Schanzenbach, Martin 
> wrote:
> 
> >
> >
> > > On 7. Sep 2022, at 14:59, madmurphy  wrote:
> > >
> > > Hi Martin,
> > >
> > > That means, if you can find out how the packages linked against
> > libcurl-compat or libcurl-gnutls are built from source, you can do the same
> > with the gnunet package.
> > > The packages in the official repositories that explicitly require
> > libcurl-gnutls (and not simply libcurl) are spotify-launcher (PKGBUILD /
> > package source code) and steam-native-runtime (PKGBUILD / no source code
> > here, it's just glue). But it is a mystery to me how they would find out.
> >
> > They probably do not distinguish between the two versions. The package
> > build simply makes sure that during linking, the correct link is set.
> >
> > >
> > > Ah look here:
> > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > The curl-compat package does link libcurl.so against the versioned files.
> > > And curl-gnutls does the same:
> > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > That libcurl-compat package compiles curl with different build settings,
> > then renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally links
> > libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0,
> > libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0,
> > libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old
> > versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0
> > remain linked to the binary shipped by the original curl package).
> > >
> > > That libcurl-gnutls package does exactly the same, but the basename of
> > the symlinks becomes libcurl-gnutls.so.* instead of simply libcurl.so.*.
> > >
> > > FYI I updated the detection logic again. You may check if that works for
> > you know.
> > > If I try to build the last GNUnet commit with libcurl-gnutls from the
> > official Arch repository I still get
> > >
> > > ...
> > > HTTP Client:curl (OpenSSL)
> > > ...
> > >
> > > while if I use my hacked libcurl-gnutls I get
> > >
> > > ...
> > > HTTP Client:curl-gnutls
> > > ...
> > >
> > > I think I found a solution. I will publish a glue package on AUR named
> > libcurl-gnutls.so, which will depend on the official libcurl-gnutls, and on
> > which GNUnet will depend. All this glue package will do is simply creating
> > an unversioned symlink.
> >
> > Yeah.. curl-config just seems to be a bash script where the supported
> > backends are hardcoded when it is "compiled".
> > So even if you install curl-gnutls it will still say "openssl"... great.
> >
> > I now commited a programmatic check for GnuTLS. Try it out. It should not
> > require your fix.
> > No idea if anybody actually ships curl with multiple TLS backends, but we
> > check on runtime anyway so its fine.
> > We may want to set the backend explicity maybe with curl_global_sslset...
> >
> > BR
> > Martin
> >
> > >
> > > --madmurphy
> > >
> > >
> > > On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach <
> > mschanzenb...@posteo.de> wrote:
> > > FYI I updated the detection logic again. You may check if that works for
> > > you know.
> > > Know that even if it detected "curl-openssl" for you the last time, it
> > > probably was correctly linked against the "drop-in" libcurl-gnutls.
> > > We just were not able to detect that.
> > >
> > > BR
> > >
> > > Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +:
> > > > Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > > > > Okay, about the libcurl-gnutls package, Martin was right. If I add
> > this
> > > > > line to the PKGBUILD of that package,
> > > > >
> > > > > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > > > >
> > > > > Everything goes well in GNUnet and the configure script prints
> > > > >
> > > > > ...
> > > > > HTTP Client:curl-gnutls
> > > > > ...
> > > > >
> > > > > Now the question is what to do. In theory I could publish my own
> > version of
> > > > > libcurl-gnutls on AUR with only that line added, and make GNUnet
> > depend on
> > > > > it. But I wonder why Arch developers did that. My guess is that for
> > > > > creating the libcurl-gnutls package they copied and hacked the
> > section of
> > > > > the PKGBUILD that builds libcurl-compat
> > > > > , which
> > is a
> 

Re: About GNUrl and cURL

[madmurphy]

I now commited a programmatic check for GnuTLS. Try it out. It should not
require your fix.

Mmm without my trick the configure script still prints

...
HTTP Client:curl (OpenSSL)
...

--madmurphy

On Wed, Sep 7, 2022 at 3:44 PM Schanzenbach, Martin 
wrote:

>
>
> > On 7. Sep 2022, at 14:59, madmurphy  wrote:
> >
> > Hi Martin,
> >
> > That means, if you can find out how the packages linked against
> libcurl-compat or libcurl-gnutls are built from source, you can do the same
> with the gnunet package.
> > The packages in the official repositories that explicitly require
> libcurl-gnutls (and not simply libcurl) are spotify-launcher (PKGBUILD /
> package source code) and steam-native-runtime (PKGBUILD / no source code
> here, it's just glue). But it is a mystery to me how they would find out.
>
> They probably do not distinguish between the two versions. The package
> build simply makes sure that during linking, the correct link is set.
>
> >
> > Ah look here:
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > The curl-compat package does link libcurl.so against the versioned files.
> > And curl-gnutls does the same:
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > That libcurl-compat package compiles curl with different build settings,
> then renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally links
> libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0,
> libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0,
> libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old
> versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0
> remain linked to the binary shipped by the original curl package).
> >
> > That libcurl-gnutls package does exactly the same, but the basename of
> the symlinks becomes libcurl-gnutls.so.* instead of simply libcurl.so.*.
> >
> > FYI I updated the detection logic again. You may check if that works for
> you know.
> > If I try to build the last GNUnet commit with libcurl-gnutls from the
> official Arch repository I still get
> >
> > ...
> > HTTP Client:curl (OpenSSL)
> > ...
> >
> > while if I use my hacked libcurl-gnutls I get
> >
> > ...
> > HTTP Client:curl-gnutls
> > ...
> >
> > I think I found a solution. I will publish a glue package on AUR named
> libcurl-gnutls.so, which will depend on the official libcurl-gnutls, and on
> which GNUnet will depend. All this glue package will do is simply creating
> an unversioned symlink.
>
> Yeah.. curl-config just seems to be a bash script where the supported
> backends are hardcoded when it is "compiled".
> So even if you install curl-gnutls it will still say "openssl"... great.
>
> I now commited a programmatic check for GnuTLS. Try it out. It should not
> require your fix.
> No idea if anybody actually ships curl with multiple TLS backends, but we
> check on runtime anyway so its fine.
> We may want to set the backend explicity maybe with curl_global_sslset...
>
> BR
> Martin
>
> >
> > --madmurphy
> >
> >
> > On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach <
> mschanzenb...@posteo.de> wrote:
> > FYI I updated the detection logic again. You may check if that works for
> > you know.
> > Know that even if it detected "curl-openssl" for you the last time, it
> > probably was correctly linked against the "drop-in" libcurl-gnutls.
> > We just were not able to detect that.
> >
> > BR
> >
> > Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +:
> > > Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > > > Okay, about the libcurl-gnutls package, Martin was right. If I add
> this
> > > > line to the PKGBUILD of that package,
> > > >
> > > > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > > >
> > > > Everything goes well in GNUnet and the configure script prints
> > > >
> > > > ...
> > > > HTTP Client:curl-gnutls
> > > > ...
> > > >
> > > > Now the question is what to do. In theory I could publish my own
> version of
> > > > libcurl-gnutls on AUR with only that line added, and make GNUnet
> depend on
> > > > it. But I wonder why Arch developers did that. My guess is that for
> > > > creating the libcurl-gnutls package they copied and hacked the
> section of
> > > > the PKGBUILD that builds libcurl-compat
> > > > , which
> is a
> > > > glue package that also does not ship the unversioned .so file
> > > > .
> Who
> > > > knows…
> > > >
> > >
> > > Ah look here:
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > The curl-compat package does link libcurl.so against the versioned
> > > files.
> > > And curl-gnutls does the same:
> 

Re: A more general question about curl

[Schanzenbach, Martin]

Imagine that a "GET /download" downloads 1GB of data.
If your code looks like this (not the actual API but for demonstration 
purposes):

data = wget_get("/download")
// Wait until download completes

Then you have a blocking API.

Instead you can have a non-blocking API that allows you to "select" or "epoll" 
file descriptors of the download.
See https://curl.se/libcurl/c/libcurl-multi.html

> On 7. Sep 2022, at 16:28, madmurphy  wrote:
> 
> I never used the curl API, so I don't know what the multi interface is, but 
> if I remember correctly wget2 introduced non-blocking sockets. That's all I 
> know. I did not find a lot of info on Google, except maybe for this email on 
> gnutls mailing list: 
> https://lists.gnutls.org/pipermail/gnutls-devel/2019-June/014051.html
> 
> --madmurphy
> 
> On Wed, Sep 7, 2022 at 2:54 PM Schanzenbach, Martin  
> wrote:
> We need a non-blocking API such as curl_multi.
> Last time I checked, libwget2 does not have that.
> 
> BR
> 
> > On 7. Sep 2022, at 15:46, madmurphy  wrote:
> >
> > I don't know all the reasons behind using curl and all GNUnet's 
> > requirements, but have you guys thought about switching to wget2? It is a 
> > GNU package and has a nice library (libwget). It supports GNU TLS natively, 
> > it is supposed to download faster than curl, and if a minor feature is 
> > missing it might be an opportunity to make libwget grow.
> >
> > A comparison table (by curl):
> >
> > https://curl.se/docs/comparison-table.html
> >
> > --madmurphy
> 



signature.asc
Description: Message signed with OpenPGP

Re: About GNUrl and cURL

[Schanzenbach, Martin]

> On 7. Sep 2022, at 14:59, madmurphy  wrote:
> 
> Hi Martin,
> 
> That means, if you can find out how the packages linked against 
> libcurl-compat or libcurl-gnutls are built from source, you can do the same 
> with the gnunet package.
> The packages in the official repositories that explicitly require 
> libcurl-gnutls (and not simply libcurl) are spotify-launcher (PKGBUILD / 
> package source code) and steam-native-runtime (PKGBUILD / no source code 
> here, it's just glue). But it is a mystery to me how they would find out.

They probably do not distinguish between the two versions. The package build 
simply makes sure that during linking, the correct link is set.

> 
> Ah look here: 
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> The curl-compat package does link libcurl.so against the versioned files.
> And curl-gnutls does the same: 
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> That libcurl-compat package compiles curl with different build settings, then 
> renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally links 
> libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0, 
> libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0, 
> libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old 
> versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0 remain 
> linked to the binary shipped by the original curl package).
> 
> That libcurl-gnutls package does exactly the same, but the basename of the 
> symlinks becomes libcurl-gnutls.so.* instead of simply libcurl.so.*.
> 
> FYI I updated the detection logic again. You may check if that works for you 
> know.
> If I try to build the last GNUnet commit with libcurl-gnutls from the 
> official Arch repository I still get
> 
> ...
> HTTP Client:curl (OpenSSL)
> ...
> 
> while if I use my hacked libcurl-gnutls I get
> 
> ...
> HTTP Client:curl-gnutls
> ...
> 
> I think I found a solution. I will publish a glue package on AUR named 
> libcurl-gnutls.so, which will depend on the official libcurl-gnutls, and on 
> which GNUnet will depend. All this glue package will do is simply creating an 
> unversioned symlink.

Yeah.. curl-config just seems to be a bash script where the supported backends 
are hardcoded when it is "compiled".
So even if you install curl-gnutls it will still say "openssl"... great.

I now commited a programmatic check for GnuTLS. Try it out. It should not 
require your fix.
No idea if anybody actually ships curl with multiple TLS backends, but we check 
on runtime anyway so its fine.
We may want to set the backend explicity maybe with curl_global_sslset...

BR
Martin

> 
> --madmurphy
> 
> 
> On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach  
> wrote:
> FYI I updated the detection logic again. You may check if that works for
> you know.
> Know that even if it detected "curl-openssl" for you the last time, it
> probably was correctly linked against the "drop-in" libcurl-gnutls.
> We just were not able to detect that.
> 
> BR
> 
> Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +:
> > Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > > Okay, about the libcurl-gnutls package, Martin was right. If I add this
> > > line to the PKGBUILD of that package,
> > >
> > > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > >
> > > Everything goes well in GNUnet and the configure script prints
> > >
> > > ...
> > > HTTP Client:curl-gnutls
> > > ...
> > >
> > > Now the question is what to do. In theory I could publish my own version 
> > > of
> > > libcurl-gnutls on AUR with only that line added, and make GNUnet depend on
> > > it. But I wonder why Arch developers did that. My guess is that for
> > > creating the libcurl-gnutls package they copied and hacked the section of
> > > the PKGBUILD that builds libcurl-compat
> > > , which is a
> > > glue package that also does not ship the unversioned .so file
> > > . Who
> > > knows…
> > >
> >
> > Ah look here: 
> > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > The curl-compat package does link libcurl.so against the versioned
> > files.
> > And curl-gnutls does the same: 
> > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> >
> > So, this would actually confirm my initial thoughts that those are
> > drop-in replacements and that we should not check for libcurl-gnutls at
> > all.
> > I have no idea how to "detect" the version of curl in this case.
> > But, I also do not think it really matters.
> > So maybe we should just remove the logic that tries to identify the curl
> > version.
> >
> > > Jacki, what do you suggest? The PKGBUILD 

Re: A more general question about curl

[madmurphy]

I never used the curl API, so I don't know what the multi interface is, but
if I remember correctly wget2 introduced non-blocking sockets. That's all I
know. I did not find a lot of info on Google, except maybe for this email
on gnutls mailing list:
https://lists.gnutls.org/pipermail/gnutls-devel/2019-June/014051.html

--madmurphy

On Wed, Sep 7, 2022 at 2:54 PM Schanzenbach, Martin 
wrote:

> We need a non-blocking API such as curl_multi.
> Last time I checked, libwget2 does not have that.
>
> BR
>
> > On 7. Sep 2022, at 15:46, madmurphy  wrote:
> >
> > I don't know all the reasons behind using curl and all GNUnet's
> requirements, but have you guys thought about switching to wget2? It is a
> GNU package and has a nice library (libwget). It supports GNU TLS natively,
> it is supposed to download faster than curl, and if a minor feature is
> missing it might be an opportunity to make libwget grow.
> >
> > A comparison table (by curl):
> >
> > https://curl.se/docs/comparison-table.html
> >
> > --madmurphy
>
>

Re: A more general question about curl

[Schanzenbach, Martin]

We need a non-blocking API such as curl_multi.
Last time I checked, libwget2 does not have that.

BR

> On 7. Sep 2022, at 15:46, madmurphy  wrote:
> 
> I don't know all the reasons behind using curl and all GNUnet's requirements, 
> but have you guys thought about switching to wget2? It is a GNU package and 
> has a nice library (libwget). It supports GNU TLS natively, it is supposed to 
> download faster than curl, and if a minor feature is missing it might be an 
> opportunity to make libwget grow.
> 
> A comparison table (by curl):
> 
> https://curl.se/docs/comparison-table.html
> 
> --madmurphy



signature.asc
Description: Message signed with OpenPGP

A more general question about curl

[madmurphy]

I don't know all the reasons behind using curl and all GNUnet's
requirements, but have you guys thought about switching to wget2? It is a
GNU package and has a nice library (libwget). It supports GNU TLS natively,
it is supposed to download faster than curl, and if a minor feature is
missing it might be an opportunity to make libwget grow.

A comparison table (by curl):

https://curl.se/docs/comparison-table.html

--madmurphy

Re: About GNUrl and cURL

[madmurphy]

Hi Martin,

That means, if you can find out how the packages linked against
libcurl-compat or libcurl-gnutls are built from source, you can do the same
with the gnunet package.

The packages in the official repositories that explicitly require
libcurl-gnutls (and not simply libcurl) are spotify-launcher
 (
PKGBUILD

/ package source code
)
and steam-native-runtime
 (
PKGBUILD

/ no source code here, it's just glue). But it is a mystery to me how they
would find out.

Ah look here:
https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
The curl-compat package does link libcurl.so against the versioned files.
And curl-gnutls does the same:
https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94

That libcurl-compat package compiles curl with different build settings,
then renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally links
libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0,
libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0,
libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old
versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0
remain linked to the binary shipped by the original curl package).

That libcurl-gnutls package does exactly the same, but the basename of the
symlinks becomes libcurl-gnutls.so.* instead of simply libcurl.so.*.

FYI I updated the detection logic again. You may check if that works for
you know.

If I try to build the last GNUnet commit

with libcurl-gnutls from the official Arch repository I still get

...
HTTP Client:curl (OpenSSL)
...

while if I use my hacked libcurl-gnutls I get

...
HTTP Client:curl-gnutls
...

I think I found a solution. I will publish a glue package on AUR named
libcurl-gnutls.so, which will depend on the official libcurl-gnutls, and on
which GNUnet will depend. All this glue package will do is simply creating
an unversioned symlink.

--madmurphy

On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach 
wrote:

> FYI I updated the detection logic again. You may check if that works for
> you know.
> Know that even if it detected "curl-openssl" for you the last time, it
> probably was correctly linked against the "drop-in" libcurl-gnutls.
> We just were not able to detect that.
>
> BR
>
> Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +:
> > Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > > Okay, about the libcurl-gnutls package, Martin was right. If I add this
> > > line to the PKGBUILD of that package,
> > >
> > > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > >
> > > Everything goes well in GNUnet and the configure script prints
> > >
> > > ...
> > > HTTP Client:curl-gnutls
> > > ...
> > >
> > > Now the question is what to do. In theory I could publish my own
> version of
> > > libcurl-gnutls on AUR with only that line added, and make GNUnet
> depend on
> > > it. But I wonder why Arch developers did that. My guess is that for
> > > creating the libcurl-gnutls package they copied and hacked the section
> of
> > > the PKGBUILD that builds libcurl-compat
> > > , which
> is a
> > > glue package that also does not ship the unversioned .so file
> > > .
> Who
> > > knows…
> > >
> >
> > Ah look here:
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > The curl-compat package does link libcurl.so against the versioned
> > files.
> > And curl-gnutls does the same:
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> >
> > So, this would actually confirm my initial thoughts that those are
> > drop-in replacements and that we should not check for libcurl-gnutls at
> > all.
> > I have no idea how to "detect" the version of curl in this case.
> > But, I also do not think it really matters.
> > So maybe we should just remove the logic that tries to identify the curl
> > version.
> >
> > > Jacki, what do you suggest? The PKGBUILD of libcurl-gnutls attached to
> this
> > > email works well for GNUnet. But for publishing on AUR we would need to
> > > rename it in some way.
> > >
> > > --madmurphy
> > >
> > > On Tue, Sep 6, 2022 at 9:06 PM Martin Schanzenbach <
> mschanzenb...@posteo.de>
> > > wrote:
> > >
> > > > Excerpts from 

Re: About GNUrl and cURL

[Martin Schanzenbach]

FYI I updated the detection logic again. You may check if that works for
you know.
Know that even if it detected "curl-openssl" for you the last time, it
probably was correctly linked against the "drop-in" libcurl-gnutls.
We just were not able to detect that.

BR

Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +:
> Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > Okay, about the libcurl-gnutls package, Martin was right. If I add this
> > line to the PKGBUILD of that package,
> > 
> > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > 
> > Everything goes well in GNUnet and the configure script prints
> > 
> > ...
> > HTTP Client:curl-gnutls
> > ...
> > 
> > Now the question is what to do. In theory I could publish my own version of
> > libcurl-gnutls on AUR with only that line added, and make GNUnet depend on
> > it. But I wonder why Arch developers did that. My guess is that for
> > creating the libcurl-gnutls package they copied and hacked the section of
> > the PKGBUILD that builds libcurl-compat
> > , which is a
> > glue package that also does not ship the unversioned .so file
> > . Who
> > knows…
> > 
> 
> Ah look here: 
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> The curl-compat package does link libcurl.so against the versioned
> files.
> And curl-gnutls does the same: 
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> 
> So, this would actually confirm my initial thoughts that those are
> drop-in replacements and that we should not check for libcurl-gnutls at
> all.
> I have no idea how to "detect" the version of curl in this case.
> But, I also do not think it really matters.
> So maybe we should just remove the logic that tries to identify the curl
> version.
> 
> > Jacki, what do you suggest? The PKGBUILD of libcurl-gnutls attached to this
> > email works well for GNUnet. But for publishing on AUR we would need to
> > rename it in some way.
> > 
> > --madmurphy
> > 
> > On Tue, Sep 6, 2022 at 9:06 PM Martin Schanzenbach 
> > wrote:
> > 
> > > Excerpts from Christian Grothoff's message of 2022-09-06 21:34:45 +0200:
> > > > On 9/6/22 14:43, madmurphy wrote:
> > > > > Just out of curiosity, why do I get
> > > > >
> > > > > gstreamer:  no
> > > >
> > > > You need also certain related gstreamer libraries
> > > > (gstreamer-plugins-base or something like that) before gstreamer is
> > > > considered "complete enough" to work for GNUnet.
> > > >
> > >
> > > I have to disagree that this is what configure.ac checks. I invite you
> > > to investigate as well. I am at a loss as what exactly the logic
> > > currently is. It sais "gstreamer no" for me, too, but conversation is
> > > built with the "gst" "backend". Whatever that means. Anyway.
> > >
> > > > -Christian
> > >


signature.asc
Description: PGP signature

Re: About GNUrl and cURL

[Martin Schanzenbach]

Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> Okay, about the libcurl-gnutls package, Martin was right. If I add this
> line to the PKGBUILD of that package,
> 
> ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> 
> Everything goes well in GNUnet and the configure script prints
> 
> ...
> HTTP Client:curl-gnutls
> ...
> 
> Now the question is what to do. In theory I could publish my own version of
> libcurl-gnutls on AUR with only that line added, and make GNUnet depend on
> it. But I wonder why Arch developers did that. My guess is that for
> creating the libcurl-gnutls package they copied and hacked the section of
> the PKGBUILD that builds libcurl-compat
> , which is a
> glue package that also does not ship the unversioned .so file
> . Who
> knows…
> 

Ah look here: 
https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
The curl-compat package does link libcurl.so against the versioned
files.
And curl-gnutls does the same: 
https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94

So, this would actually confirm my initial thoughts that those are
drop-in replacements and that we should not check for libcurl-gnutls at
all.
I have no idea how to "detect" the version of curl in this case.
But, I also do not think it really matters.
So maybe we should just remove the logic that tries to identify the curl
version.

> Jacki, what do you suggest? The PKGBUILD of libcurl-gnutls attached to this
> email works well for GNUnet. But for publishing on AUR we would need to
> rename it in some way.
> 
> --madmurphy
> 
> On Tue, Sep 6, 2022 at 9:06 PM Martin Schanzenbach 
> wrote:
> 
> > Excerpts from Christian Grothoff's message of 2022-09-06 21:34:45 +0200:
> > > On 9/6/22 14:43, madmurphy wrote:
> > > > Just out of curiosity, why do I get
> > > >
> > > > gstreamer:  no
> > >
> > > You need also certain related gstreamer libraries
> > > (gstreamer-plugins-base or something like that) before gstreamer is
> > > considered "complete enough" to work for GNUnet.
> > >
> >
> > I have to disagree that this is what configure.ac checks. I invite you
> > to investigate as well. I am at a loss as what exactly the logic
> > currently is. It sais "gstreamer no" for me, too, but conversation is
> > built with the "gst" "backend". Whatever that means. Anyway.
> >
> > > -Christian
> >


signature.asc
Description: PGP signature

Re: About GNUrl and cURL

[Martin Schanzenbach]

Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> Okay, about the libcurl-gnutls package, Martin was right. If I add this
> line to the PKGBUILD of that package,
> 
> ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> 
> Everything goes well in GNUnet and the configure script prints
> 
> ...
> HTTP Client:curl-gnutls
> ...
> 
> Now the question is what to do. In theory I could publish my own version of
> libcurl-gnutls on AUR with only that line added, and make GNUnet depend on
> it. But I wonder why Arch developers did that. My guess is that for
> creating the libcurl-gnutls package they copied and hacked the section of
> the PKGBUILD that builds libcurl-compat
> , which is a
> glue package that also does not ship the unversioned .so file
> . Who
> knows…
> 

My guess is that libcurl-compat and libcurl-gnutls are used by some
packages that are already linked against them.
They are just not useful for development.
That means, if you can find out how the packages linked against
libcurl-compat or libcurl-gnutls are built from source, you can do the
same with the gnunet package.

> Jacki, what do you suggest? The PKGBUILD of libcurl-gnutls attached to this
> email works well for GNUnet. But for publishing on AUR we would need to
> rename it in some way.
> 
> --madmurphy
> 
> On Tue, Sep 6, 2022 at 9:06 PM Martin Schanzenbach 
> wrote:
> 
> > Excerpts from Christian Grothoff's message of 2022-09-06 21:34:45 +0200:
> > > On 9/6/22 14:43, madmurphy wrote:
> > > > Just out of curiosity, why do I get
> > > >
> > > > gstreamer:  no
> > >
> > > You need also certain related gstreamer libraries
> > > (gstreamer-plugins-base or something like that) before gstreamer is
> > > considered "complete enough" to work for GNUnet.
> > >
> >
> > I have to disagree that this is what configure.ac checks. I invite you
> > to investigate as well. I am at a loss as what exactly the logic
> > currently is. It sais "gstreamer no" for me, too, but conversation is
> > built with the "gst" "backend". Whatever that means. Anyway.
> >
> > > -Christian
> >


signature.asc
Description: PGP signature