Debian Patches

Status for curl/8.20.0-4

Patch Description Author Forwarded Bugs Origin Last update
ZZZgnutls-build.patch Build with GnuTLS. Steve McIntyre <93sam@debian.org> not-needed vendor 2024-11-06
build-Divide-mit-krb5-gssapi-link-flags-between-LDFLAGS-a.patch build: Divide mit-krb5-gssapi link flags between LDFLAGS and LIBS
From the comments nearby about not having --libs-only-L, it looks as
though the intention was to apply a split like this to all dependency
libraries where possible, and the only reason it was not done for
Kerberos is that krb5-config doesn't have that feature and pkg-config
was originally not supported here. For example, zlib, libssh and librtmp
all have their flags from pkg-config split in this way.

Now that pkg-config is supported here, we can do the intended split.		 Simon McVittie <smcv@collabora.com> no 2022-11-22
11_omit-directories-from-config.patch Omit directories embedding arch info from curl-config
In order to (partially) multi-arch-ify curl-config, remove all
mention of @includedir@ and @libdir@ from the script. On Debian, the actual
header and library directories are architecture-dependent, but will always be
in the C compiler's default search path, so -I and -L options are not
necessary (and may be harmful in multi-arch environments.)		 Benjamin Moody <benjamin.moody@gmail.com> not-needed debian vendor 2025-02-05
event-fix-wakeup-consumption.patch event: fix wakeup consumption
The events on a multi wakeup socketpair were only consumed via
curl_multi_poll()/curl_multi_wait() but not in event based processing on
a curl_multi_socket() call. That led to busy loops as reported in

Fixes #21547
Closes #21549		 Stefan Eissing <stefan@eissing.org> yes debian upstream upstream, https://github.com/curl/curl/commit/2a2104f3cff44bb28bb570a093be52bbeeed8f23 2025-05-13
Implement-symbol-versioning-for-CURL_GNUTLS_3.patch Implement symbol versioning for CURL_GNUTLS_3
This is a big and complex patch we have to carry due to a mistake in
another patch that slipped under our radar when libcurl-gnutls' soname
version was bumped from 3 to 4.

We have a local patch (ZZZgnutls-build.patch) that's used to adjust
curl's build system so that we can build two versions of libcurl: one
against OpenSSL, and another against GNUTLS. It's a hack but it
works. The problem is that it used to contain (up until this patch
was devised, that is) a change that *always* set libcurl-gnutls'
soname version to 3. That was OK while upstream used the same soname
version for the library, but things got bad when upstream did an
soname bump.

Because the patch only applies to libcurl-gnutls, that library's
soname version was pinned to 3. However, when building libcurl (which
links against OpenSSL), the patch did not have any effect and
upstream's soname bump was correctly adopted by our libcurl package.
This created a situation where we now have a libcurl4
package (providing the OpenSSL-version of the library) and a
libcurl3-gnutls (providing the GNUTLS version of the library).

The situation got even worse because the symbols generated when
building libcurl3-gnutls were (incorrectly) versioned with
"@CURL_GNUTLS_3", even though they should have been versioned
"@CURL_GNUTLS_4". It's bad.

Long story short, we had to fix the issue. The only sensible way to
do so was to adjust ZZZgnutls-build.patch so that it doesn't pin
libcurl-gnutls' soname version anymore, but there's a problem: now
when building the library, all symbols are (correctly) versioned as
"@CURL_GNUTLS_4", which means that all programs that previously linked
against libcurl3-gnutls would not work anymore. What can we do?
Leverage symbol versioning tricks to make everything work for the old
programs (depending on "@CURL_GNUTLS_3" symbols) while providing the
correct "@CURL_GNUTLS_4" symbols as the default ones. This is what
this patch does.

Unfortunately that wasn't very easy to do without resorting to certain
"tricks". Here's an explanation of each one:

* The patch creates a new symbol for each function that was previously
versioned as "@CURL_GNUTLS_3" (according to
d/libcurl3t64-gnutls.symbols). This new symbol is versioned as
"@@@CURL_GNUTLS_4". The "@@@" part tells the dynamic loader that
this symbol is the default version *and* instructs the linker
to *remove* the previously undefined symbol. For example, if a
function's name is "curl_foo" then the linker will generate a symbol
called "curl_foo@@@CURL_GNUTLS_4" and remove "curl_foo" when
compiling. The loader will resolve "curl_foo" (unversioned) to
"curl_foo@@@CURL_GNUTLS_4" automatically.

* The patch creates a new function declaration for each of the
functions mentioned above, but named "__curl_compat_FUNCTION_NAME".
This new symbol is marked as an alias of "curl_FUNCTION_NAME", and
its visibility is set to "default" so that we can create the
"@CURL_GNUTLS_3" version of the "curl_FUNCTION_NAME" symbol.

* The patch creates a new symbol version for
"__curl_compat_FUNCTION_NAME" named
"curl_FUNCTION_NAME@CURL_GNUTLS_3". This symbol is hidden by
default so new users won't link against it, but it's also available
in case old programs still need it.

* All this symbol creation dance should only be performed when (a)
we're building the GNUTLS version of libcurl, and (b) we are *not*
building a static libcurl (in which case the symbol versioning would
generate errors).

* The patch also needs to create a new version of libcurl's version
script especially crafted for libcurl-gnutls. In it, we define the
"@CURL_GNUTLS_3" symbols we want to export and then define
"@CURL_GNUTLS_4" in terms of it.		 Sergio Durigan Junior <sergiodj@debian.org> not-needed debian 2026-05-05

All known versions for source package 'curl'

Links