Page MenuHome GnuPG

How to maintain our local libtool patch
Closed, ResolvedPublic

Description

We have our local libtool change in libgpg-error, libassuan, libgcrypt, etc., so that the DLL for x86_64 has different file name.

Currently, we maintain our own ltmain.sh, but when a user runs libtoolize by herself, it is ignored.

Event Timeline

gniibe triaged this task as Normal priority.
gniibe created this task.

How about the change like:

From 4deec087f9b98c09ad0724754ea192c410eca5e9 Mon Sep 17 00:00:00 2001
From: NIIBE Yutaka <gniibe@fsij.org>
Date: Thu, 27 Jul 2023 16:19:00 +0900
Subject: [PATCH Libgpg-error] build: Apply libtool.patch at the last stage of
 configure.

* build-aux/libtool.patch: New.
* build-aux/ltmain.sh: Revert our local change to original.
* configure.ac: Apply build-aux/libtool.patch at the last stage.

--

It's not perfect (say, running config.status doesn't update libtool
correctly), but it's better than keep the ltmain.sh locally.

Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
---
 build-aux/libtool.patch | 45 +++++++++++++++++++++++++++++++++++++++++
 build-aux/ltmain.sh     | 14 +------------
 configure.ac            | 11 ++++++++++
 3 files changed, 57 insertions(+), 13 deletions(-)
 create mode 100644 build-aux/libtool.patch

diff --git a/build-aux/libtool.patch b/build-aux/libtool.patch
new file mode 100644
index 0000000..cc1340e
--- /dev/null
+++ b/build-aux/libtool.patch
@@ -0,0 +1,45 @@
+#
+# We used to maintain our local changes to ltmain.sh.
+#
+# But it doesn't work well when a user tries to run libtoolize with
+# newer libtool on his system.
+#
+# So, instead of keeping a change in ltmain.sh, we introduce patching
+# libtool, at the last stage of configure just libtool is generated.
+#
+# When new libtool is released, please update this patch.  Currently,
+# we assume:
+#
+# package_revision=2.4.7
+#
+
+--- libtool.orig	2023-07-27 15:45:41.026220580 +0900
++++ libtool	2023-07-27 11:20:52.933295428 +0900
+@@ -9016,6 +9016,11 @@
+ 	    elif test -n "$soname_spec"; then
+ 	      # bleh windows
+ 	      case $host in
++              x86_64-*mingw32*)
++                func_arith $current - $age
++		major=$func_arith_result
++		versuffix="6-$major"
++		;;
+ 	      *cygwin* | mingw* | *cegcc* | *os2*)
+ 	        func_arith $current - $age
+ 		major=$func_arith_result
+@@ -9794,7 +9799,14 @@
+ 	  # extension on DOS 8.3 file systems.
+ 	  func_arith $current - $age
+ 	  major=$func_arith_result
+-          versuffix="-$major"
++          case $host in
++          x86_64-*mingw32*)
++             versuffix="6-$major"
++             ;;
++          *)
++             versuffix="-$major"
++             ;;
++          esac
+ 	  ;;
+ 
+ 	*)
diff --git a/build-aux/ltmain.sh b/build-aux/ltmain.sh
index ab1b7dc..f495350 100644
--- a/build-aux/ltmain.sh
+++ b/build-aux/ltmain.sh
@@ -8497,11 +8497,6 @@ func_mode_link ()
 	    elif test -n "$soname_spec"; then
 	      # bleh windows
 	      case $host in
-              x86_64-*mingw32*)
-                func_arith $current - $age
-		major=$func_arith_result
-		versuffix="6-$major"
-		;;
 	      *cygwin* | mingw* | *cegcc* | *os2*)
 	        func_arith $current - $age
 		major=$func_arith_result
@@ -9280,14 +9275,7 @@ func_mode_link ()
 	  # extension on DOS 8.3 file systems.
 	  func_arith $current - $age
 	  major=$func_arith_result
-          case $host in
-          x86_64-*mingw32*)
-             versuffix="6-$major"
-             ;;
-          *)
-             versuffix="-$major"
-             ;;
-          esac
+          versuffix="-$major"
 	  ;;
 
 	*)
diff --git a/configure.ac b/configure.ac
index ca7731c..8664468 100644
--- a/configure.ac
+++ b/configure.ac
@@ -737,6 +737,17 @@ AC_CONFIG_FILES([src/gpg-error-config-test.sh], [chmod +x src/gpg-error-config-t
 
 AC_OUTPUT
 
+#
+# Apply a patch to libtool
+#
+case $host in
+  x86_64-*mingw32*)
+  patch -p0 < $srcdir/build-aux/libtool.patch
+  ;;
+  *)
+  ;;
+esac
+
 tmp=
 if test "$have_w32_system" != yes; then
    if test x"$gl_use_threads" = xno; then
-- 
2.39.2

I learned that AC_CONFIG_COMMANDS macro can be used to improve the case of config.status.

That assumes that libtool won't change substantially as it did several times in the past and broke our cross compiling stuff. But as long as we keep the ltmain.sh in our repo and tarball the patch is okay because it better documents the chnages.

OTOH, these changes need to be done to all our libs. Thus I would suggest to try this only for one lib (gpgrt) and wait until we need more changes for future plans.

gniibe changed the task status from Open to Testing.EditedJul 28 2023, 6:36 AM

Pushed the change to libgpg-error.

I realized that Debian ships libgpg-error, libassuan, etc. for Windows 64-bit. For the packaging applying this kind of change would be better (than ignoring our local change).

gniibe mentioned this in Unknown Object (Event).Jul 31 2023, 9:22 AM

I pushed the commit: rE64532db11fcd: build: New configure option --with-libtool-modification.

It is basically for downstream distribution(s), which might need to keep their past decision of ignoring our libtool change (either intended or unintended), and/or need to avoid a risk of dynamic patching.
For Windows 64-bit build, they can use --libtool-modification=try or --libtool-modification=never.

Until libtool will introduce soname change by configure time option, this is our method to keep our local modification.

Please note that our modifications against libtool were ones for:

  • Power 64-bit
  • Android
  • Windows 64-bit (in the current discussion)

New libtool 2.4.7 already has changes needed for Power 64-bit and Android, and remained is only for Windows 64-bit.

gniibe mentioned this in Unknown Object (Event).Aug 7 2023, 7:36 AM
gniibe mentioned this in Unknown Object (Event).Aug 14 2023, 9:47 AM

Pushed the change to:

  • libgpg-error
  • libassuan master
  • libgcrypt master
  • ntbtls
  • npth
  • libksba
  • gpgme
  • scute
gniibe mentioned this in Unknown Object (Event).Aug 21 2023, 8:55 AM
gniibe mentioned this in Unknown Object (Event).Aug 28 2023, 6:40 AM
gniibe mentioned this in Unknown Object (Event).Sep 4 2023, 6:36 AM

With today's release of npth everything should be set.