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
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Few hours ago I reported a bug, and I thought that I had found my problem (  FS#75824  ). But as it appears from this discussion on GNUnet Developers mailing list, the problem was somewhere else ( https://lists.gnu.org/archive/html/gnunet-developers/2022-09/threads.html#00007 ).

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:
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
Comment by Toolybird (Toolybird) - Sunday, 11 September 2022, 02:46 GMT
So again as per  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/
Comment by Toolybird (Toolybird) - Sunday, 11 September 2022, 03:07 GMT
> So when the GNUnet configure script compiles and links a test binary then tries to run it, it fails

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;
}
Comment by grufo (grufo) - Sunday, 11 September 2022, 18:41 GMT
Hi Toolybird,

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.
Comment by Christian Hesse (eworm) - Monday, 12 September 2022, 07:50 GMT
I do not see why this patch should change anything... Basically it is just renaming a number of Makefile targets.

Possibly the issue is that we have `--disable-versioned-symbols` in our configure options?
Comment by Toolybird (Toolybird) - Monday, 12 September 2022, 08:18 GMT
@eworm, maybe I didn't explain it well enough. This is the Debian lib:

$ 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.
Comment by Christian Hesse (eworm) - Monday, 12 September 2022, 08:50 GMT
Ah, got it.
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.
Comment by Christian Hesse (eworm) - Monday, 12 September 2022, 08:54 GMT Comment by grufo (grufo) - Monday, 12 September 2022, 13:55 GMT
Hi Christian,

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.
Comment by grufo (grufo) - Monday, 12 September 2022, 14:17 GMT
I checked. I confirm that with Debian's patch gnunet's configure script prints:

HTTP Client: curl (GnuTLS)
Comment by Christian Hesse (eworm) - Monday, 12 September 2022, 14:34 GMT
Same with curl (libcurl-gnutls) from [testing]. Please give it a try...
Comment by grufo (grufo) - Monday, 12 September 2022, 15:14 GMT
We found two alternative solutions at the same time, I think. I tested your new package and it seems to work. In the meanwhile I have found a way to reproduce Debian's patch exactly... without using a patch (!). All it's needed is adding a few lines of code to the PKGBUILD. The file attached should explain it well enough (but a review is welcomed).

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.
Comment by grufo (grufo) - Monday, 12 September 2022, 15:20 GMT
P.S. There were two redundant lines in my last attachment. I have removed them in the AUR package.
Comment by Toolybird (Toolybird) - Monday, 12 September 2022, 21:57 GMT
Using patchelf seems kinda hackish, but hey, you're the one getting paid the big $$$ :)

The pkg in testing allows gnunet-git to build against it, but that was the limit of my testing.

Loading...