Re: About GNUrl and cURL

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
<https://archlinux.org/packages/community/x86_64/spotify-launcher/> (
PKGBUILD
<https://github.com/archlinux/svntogit-community/blob/packages/spotify-launcher/trunk/PKGBUILD>
/ package source code
<https://github.com/kpcyrd/spotify-launcher/archive/refs/tags/v0.3.0.tar.gz>)
and steam-native-runtime
<https://archlinux.org/packages/multilib/x86_64/steam-native-runtime/> (
PKGBUILD
<https://github.com/archlinux/svntogit-community/blob/packages/steam-native-runtime/trunk/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
<https://git.gnunet.org/gnunet.git/tree/?id=6745bed70af20a11aee5e0c8f6e7bd8479031e9e>
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 <[email protected]>
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 +0000:
> > 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
> > > <https://archlinux.org/packages/core/x86_64/libcurl-compat/>, which
> is a
> > > glue package that also does not ship the unversioned .so file
> > > <https://archlinux.org/packages/core/x86_64/libcurl-compat/files/>.
> 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 <
> [email protected]>
> > > 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
> > > >
>