Page MenuHome GnuPG

macOS 11 or newer support: Update libtool
Closed, ResolvedPublic


In GnuPG and its friends, libtool is maintained locally.
Now, it's better to merge some updates from upstream.
(Unfortunately, upstream development has been stopped.)

Event Timeline

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


And update from automake 1.16:


We have our own changes for and libtool.m4.

werner added a project: MacOS.
werner added a subscriber: werner.

macOS has low priority for us and I do not want to risk any regression.

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' ;;
 	  _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
-	10.*)
+	10.*|11.*)
 	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;

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' ;;
       _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' ;;

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 ( libtool formula which is where I originally got libtool.m4, see:

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:

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

gniibe renamed this task from Update libtool to macOS 11 or newer support: Update libtool.Sep 27 2021, 3:31 AM

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:

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