gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About GNUrl and cURL


From: madmurphy
Subject: Re: About GNUrl and cURL
Date: Wed, 7 Sep 2022 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 <mschanzenbach@posteo.de> wrote:


> On 7. Sep 2022, at 14:59, madmurphy <madmurphy333@gmail.com> 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 <mschanzenbach@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 +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 <mschanzenbach@posteo.de>
> > > 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
> > > >


reply via email to

[Prev in Thread] Current Thread [Next in Thread]