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.
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.
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T6508 Port GnuPG to 64-bit Windows | ||
Resolved | • gniibe | T6484 dll: 64-bit different name for libgcrypt, libksba, ntbtls, and gpgme | ||
Resolved | • gniibe | T6619 How to maintain our local libtool patch |
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.
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).
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:
New libtool 2.4.7 already has changes needed for Power 64-bit and Android, and remained is only for Windows 64-bit.
Pushed the change to: