Put it under lower priority, as it's basically programming error.

Here is my proposal to avoid unsynched state for data.

diff --git a/src/client.c b/src/client.c
index 410f940..0989984 100644
--- a/src/client.c
+++ b/src/client.c
@@ -250,6 +250,7 @@ assuan_transact (assuan_context_t ctx,
   int off;
   char *line;
   int linelen;
+  gpg_error_t last_err = 0;

I have confirmed that rA69069bc63e6b fixes the build on macOS.

Fixed in libassuan 3.0.0.

Fixed in: rA69069bc63e6b: Remove an declaration for an unused function

Actually we should get rid of stdio functions and use the es_foo replacements from libgpg-error.

The socklen_t use are now being fixed in newer POSIX Issue 8, 2024.
https://www.man7.org/linux/man-pages/man3/socklen_t.3type.html

Yes, the SO number changed. Before that you had run the test with an old version of the library or maybe the current one depending on your system. However, a changed SO number means that you have can have two versions of the library installed and they don't alias them with symlinks. We rarely update SO numbers but int he libassuan case we did it because technically we had a minor ABI change but GnuPG and Cie. are not affected; we did it anyway to be correct.

Debian uses symbol versions to help with library transition. See https://lists.gnupg.org/pipermail/gnupg-devel/2024-June/035587.html for more. Although I am not sure whether this is a good idea, I just released a new version 3.0.1 with just a chnage in the symbol versioning. See rAc9e902705a

Now also done for libksba.

Done in 3.0.0.

Done in 3.0.0.

Done in 3.0.0.

Added in 3.0.0.

It's tested by gnupg master (for gnupg26) for a year. Let us move on.

I think we should close this bug or re-purpose it to silence those warnings in common cases.

Pushed the change into master of libassuan (to be 3.0).