|
| From: | madmurphy |
| Subject: | Re: About GNUrl and cURL |
| Date: | Wed, 7 Sep 2022 13:59:43 +0100 |
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
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
> > >
| [Prev in Thread] | Current Thread | [Next in Thread] |