Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/link_all_deplibs.patch
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/netbsdelf.patch

It's better to update the set of files from libtool:

build-aux/ltmain.sh
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4

And update from automake 1.16:

build-aux/compile
build-aux/depcomp
build-aux/install-sh
build-aux/missing

We have our own changes for ltmain.sh and libtool.m4.

About merging our local changes.

For ltmain.sh:

• We can ignore rE0fe34500c2dc: Add some code to build nativley under WindowsCE - not finished.
• The change in rEdd05f3790e53: Fix libtool 2.4.2 to correctly detect .def files. for .def file is no need to apply; it is handled correctly now by func_dll_def_p function.
• We need to apply rEca46b9a7bccb: Add hack to have different names for 64 bit Windows DLLs. rEc58e487cbdd3: Convert http links to https where possible in the source.

For libtool.m4:

• We need to apply rEc58e487cbdd3: Convert http links to https where possible in the source.
• The change in rEdd05f3790e53: Fix libtool 2.4.2 to correctly detect .def files. for .def files is no need to appy; it is handled correctly now.
• rEbf0d67dbfa41: Update libtool to support Android. was from upstream
• better change is in upstream rE0b192cff772b: Add build support for ppc64le.
• RC file handling: rE41d753e21eaa: build: Update to new autoconf constructs., rE845c2608bb34: 2009-06-23 Marcus Brinkmann <marcus@g10code.de>

I misunderstood as if we need to update libtool from upstream.

What we really need may be... actually one- line patch of macOS specific (or something like that):

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 8795701..a83d3f1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1054,7 +1054,7 @@ _LT_EOF
 	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
 	10.[[012]]*)
 	  _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
-	10.*)
+	10.*|11.*)
 	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
       esac
     ;;

That does indeed not look like something which could introduce a regression.

That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 8795701e..77d62f75 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1045,16 +1045,11 @@ _LT_EOF
       _lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
     darwin1.*)
       _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
-    darwin*) # darwin 5.x on
-      # if running on 10.5 or later, the deployment target defaults
-      # to the OS version, if on x86, and 10.4, the deployment
-      # target defaults to 10.4. Don't you love it?
-      case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
-       10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
-         _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
-       10.[[012]]*)
+    darwin*)
+      case ${MACOSX_DEPLOYMENT_TARGET},$host in
+        10.[[012]],*|,*powerpc*)
          _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
-       10.*)
+       *)
          _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
       esac
     ;;

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:

https://github.com/Homebrew/homebrew-core/blob/master/Formula/libtool.rb#L20

The patch was provided to libtool-patches mailing list but it seems it hasn't been applied (maybe that was not the right place to send patches?), but it certainly fixes the issue.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

I'm going to apply a patch to our local (somewhat old) libtool in GnuPG and its friends, backporting the change.

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Note that the change and rebuild will introduce ABI change for macOS.

These are great news. Thank you!

In the meantime (while there's no new release), I have sent patches to Homebrew:

https://github.com/Homebrew/homebrew-core/pull/85973
https://github.com/Homebrew/homebrew-core/pull/85974

Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.

Also applied to gpgme.