Re: About GNUrl and cURL

No, libcurl.so is a symlink to libcurl.so.4.8.0. However my glue package
<https://aur.archlinux.org/packages/libcurl-gnutls.so> (a super-minimal
<https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libcurl-gnutls.so>
one) now provides a libcurl-gnutls.so, which is a symlink to
libcurl-gnutls.so.4.8.0.

By the way, after the last commits GNUnet's configure script does not
detect libcurl-gnutls also with my glue package (config.log attached).
However I just discovered these two packages in that fantastic place that
is AUR: libcurl-gnutls-minimal-git
<https://aur.archlinux.org/packages/libcurl-gnutls-minimal-git>,
libcurl3-gnutls <https://aur.archlinux.org/packages/libcurl3-gnutls>. I
think I should definitely give them a try.

--madmurphy

On Thu, Sep 8, 2022 at 7:55 AM Martin Schanzenbach <[email protected]>
wrote:

> I checked the log and the test runs correctly.
> The condition
>
> CURLSSLSET_OK != curl_global_sslset(CURLSSLBACKEND_GNUTLS, NULL, &avail))
>
> is evaluated against "-lcurl" and it is false.
> Hence the library linked against (-lcurl) does not support GnuTLS.
> The detection works.
> Are you sure that your libcurl.so is linked against the
> libcurl-gnutls.so* files?
>
> BR
>
> Excerpts from madmurphy's message of 2022-09-08 06:49:00 +0100:
> > 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 <
> [email protected]>
> > 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 <
> > > [email protected]>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On 7. Sep 2022, at 14:59, madmurphy <[email protected]>
> 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 <
> > > > > [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
> > > > > > > > >
> > > > >
> > > > >
> > >
>