FS#75835 - [libcurl-gnutls] uses wrong soname
Attached to Project:
Arch Linux
Opened by grufo (grufo) - Wednesday, 07 September 2022, 01:04 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 14 September 2022, 09:19 GMT
Opened by grufo (grufo) - Wednesday, 07 September 2022, 01:04 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 14 September 2022, 09:19 GMT
|
Details
Description:
Few hours ago I reported a bug, and I thought that I had found my problem ( In fact, the libcurl-gnutls package does not install any `libcurl-gnutls.so` file, without version appended (i.e., it installs `libcurl-gnutls.so.4`, `libcurl-gnutls.so.4.8.0`, and so on, but not `libcurl-gnutls.so` – see https://archlinux.org/packages/core/x86_64/libcurl-gnutls/files/). And as a consequence GNUnet is unable to find the `libcurl-gnutl` package. The problem comes from these lines from libcurl-gnutls PKGBUILD: https://github.com/archlinux/svntogit-packages/blob/3c707ad5fd07729f386703268a932905dbaaa543/trunk/PKGBUILD#L111-L115 The patch attached to this email solves the problem (to be applied to the PKGBUILD). Additional info: * package version(s) * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: 
libcurl-gnutls-generate-unver...
(0.5 KiB)
|
This task depends upon
Closed by Christian Hesse (eworm)
Wednesday, 14 September 2022, 09:19 GMT
Reason for closing: Fixed
Additional comments about closing: curl 7.85.0-2
Wednesday, 14 September 2022, 09:19 GMT
Reason for closing: Fixed
Additional comments about closing: curl 7.85.0-2
FS#75824, this doesn't actually solve any problem. Just installing the symlink is basically a hack. This is because the embedded SONAME is actually pointing to the "normal" non-tls libcurl:$ readelf -d /usr/lib/libcurl-gnutls.so.4.8.0 | grep soname
0x000000000000000e (SONAME) Library soname: [libcurl.so.4]
So when the GNUnet configure script compiles and links a test binary then tries to run it, it fails because the tls symbols are simply not there. To fix this properly, I'm fairly certain we would need to apply a similar patch to Debian [1]. Then the GNUnet detection routines in the configure script should find the correct output.
It's up to the Arch PM to decide if this is worth implementing.
[1] https://sources.debian.org/patches/curl/7.85.0-1/90_gnutls.patch/
Just to be clear, the symlink allows to the configure test program to compile and *link*. It's when the configure test tries to *run* the test program that it goes pear-shaped. This is the test prog that returns 1 instead of the expected 0
#include <curl/curl.h>
int
main (void)
{
return (CURLSSLSET_OK != curl_global_sslset(CURLSSLBACKEND_GNUTLS, NULL, NULL));
;
return 0;
}
Yes, I had a long exchange with GNUnet developers about this, in which we realized that the tls symbols were simply missing in Arch. As soon as I will have a bit of time I will upload a package on AUR copying the Debian approach.
Possibly the issue is that we have `--disable-versioned-symbols` in our configure options?
$ readelf -d libcurl-gnutls.so.4.8.0 | grep soname
0x000000000000000e (SONAME) Library soname: [libcurl-gnutls.so.4]
Compare that to the Arch output above and you can see the difference. This is the crux of the problem.
I would like to avoid huge patches changing all of the build system, though... Wondering if we could just use `patchelf` to tweak the library.
https://pkgbuild.com/~eworm/libcurl-gnutls-7.85.0-2-x86_64.pkg.tar.zst
With your package the configure script of gnunet-git still prints:
HTTP Client: curl (OpenSSL)
So the gnutls backend is not detected (you need to replace "gnurl" with "libcurl-gnutls" in the PKGBUILD before launching makepkg and check).
The reason why a solution should be found is that gnurl (which basically is a patched version of curl) is not being developed anymore, as gnunet works well with libcurl-gnutls. I have been told that Debian's libcurl-gnutls works fine.
HTTP Client: curl (GnuTLS)
By the way, I have published my package on AUR:
https://aur.archlinux.org/packages/libcurl-gnutls.so
If we find a solution in the official repository I will ask for the deletion of the AUR package.
The pkg in testing allows gnunet-git to build against it, but that was the limit of my testing.