My very last commit actually broke it again (fixed now) but see buildbot for an example that in debian, curl-gnutls is detected correctly:
https://buildbot.gnunet.org/#/builders/13/builds/133/steps/2/logs/configure > On 8. Sep 2022, at 09:46, madmurphy <madmurphy...@gmail.com> wrote: > > No, libcurl.so is a symlink to libcurl.so.4.8.0. However my glue package (a > super-minimal 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, libcurl3-gnutls. I think I should definitely give > them a try. > > --madmurphy > > > On Thu, Sep 8, 2022 at 7:55 AM Martin Schanzenbach <mschanzenb...@posteo.de> > 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 <mschanzenb...@posteo.de> > > 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 <madmurphy...@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 < > > > > > 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 > > > +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 < > > > > > mschanzenb...@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 > > > > > > > > > > > > > > > > > > > > > > > <config.log.zip>
signature.asc
Description: Message signed with OpenPGP
