GNU bug report logs -
#79468
libtool-2.6.0 released [alpha]
Previous Next
To reply to this bug, email your comments to 79468 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Thu, 18 Sep 2025 15:05:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-libtool <at> gnu.org.
(Thu, 18 Sep 2025 15:05:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.6.0, a
alpha release.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.
Here is the announcement on Savannah:
https://savannah.gnu.org/news/?id=10814
There have been 68 commits by 19 people in the 43 weeks since 2.5.4.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
The following people contributed changes to this release:
Anthony Mallet (1)
Bruno Haible (2)
Christian Feld (1)
Collin Funk (1)
Elizabeth Figura (1)
Evgeny Grin (1)
Frédéric Bérat (1)
Gleb Popov (1)
Ileana Dumitrescu (47)
Julien ÉLIE (1)
Karl Berry (1)
Kirill Makurin (1)
Manoj Gupta (1)
Martin Storsjö (1)
Michael Haubenwallner (2)
Mintsuki (1)
Mitch (1)
Pierre Ossman (2)
Takashi Yano (1)
Ileana
[on behalf of the libtool maintainers]
==================================================================
Here is the GNU libtool home page:
https://gnu.org/s/libtool/
Here are the compressed sources:
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.gz (2.1MB)
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.xz (1.1MB)
Here are the GPG detached signatures:
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.gz.sig
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
File: libtool-2.6.0.tar.gz
SHA1 sum: 681b41409762acb07232d7af7c289cc8a2f851c9
SHA256 sum:
ac9d4b8e072aa20d030d5ae039aba3b52bd7967b09e0c21f91f3e3dc1bbb8755
File: libtool-2.6.0.tar.xz
SHA1 sum: dff32acab30a9262d19c3559092c2415b6a2b23e
SHA256 sum:
69e6d28ae880fda08e0dc080ef2e38077ea2765a0d84e1afcfcfe1e605c911ac
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify libtool-2.6.0.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa4096 2021-09-23 [SC]
FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid Ileana Dumitrescu <ileanadumi95 <at> protonmail.com>
uid Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key ileanadumi95 <at> protonmail.com
gpg --recv-keys 6570EA01146F7354
wget -q -O-
'https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1'
| gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.6.0.tar.gz.sig
This release is based on the libtool git repository, available as
git clone https://git.savannah.gnu.org/git/libtool.git
with commit e40fdc22cf727fb885f9df7d9affa827e3253d1c tagged as v2.6.0.
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.6.0
or run this command from a git-cloned libtool directory:
git shortlog v2.5.4..v2.6.0
This release was bootstrapped with the following tools:
Autoconf 2.72e
Automake 1.18.1
Gnulib 2025-07-29 f0773a994eb75ceeeb44e39145c842044357a1ad
NEWS
* Noteworthy changes in release 2.6.0 (2025-09-18) [alpha]
** New features:
- Add a new tool, libtool-next-version, to guide users through updating
library versions.
- Add tagging for Objective-C and Objective-C++, OBJC and OBJCXX.
- Increase 5 digit limit on revision value for libraries to 19 digits,
which is referencing Unix epoch time in nanoseconds.
- Add configuration options to choose whether to use '-nostdlib' to let
the compiler frontend decide what standard libraries to link when
building C++ shared libraries and modules, --enable-cxx-stdlib and
--disable-cxx-stdlib.
- Allow statically linking GCC and Clang compiler support libraries
into shared libraries.
- Add linking clang_rt static archives compiler internal libraries by
their absolute path.
- Set 'mklink' as the symlinking tool for MSVC.
- Pass '--target' architecture flag for Clang.
- Support MSYS and MSYS2 file path conversions.
** Bug fixes:
- Fix wrongly deduplicated compiler dependencies on linux.
- Fix NetBSD postdeps for shared libraries.
- Fix statically linking dependencies into shared C++ libraries when
utilizing clang builtins or g++ options like, -static-libstdc++, by
using a new configuration option, --enable-cxx-stdlib.
- Ensure *-linux-mlibc host matches to mlibc userland rather than
matching to GNU/Linux and similar userlands.
- Fix hang with cmd.exe in MSYS.
- For MSVC, fix mishandling compiler flags, symlinking, cl.exe '.exp'
extension collision, symbol names, and numerous testsuite bugs.
- Fix undeclared reference to access on Windows in libltdl.
- Fix flang -Wl flags on FreeBSD.
- Fix reordering '--as-needed' flag.
- Fix libltdl early failures for multi-arch.
** Changes in supported systems or compilers:
- Support additional Intel OneAPI compilers, 'icx', 'icpx', and 'ifx'.
- Support ML64 (Microsoft Macro Assembler).
Enjoy!
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 19 Sep 2025 14:13:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Ubuntu 24.04/x86_64 I get these test failures:
65: passing OBJCXX flags through libtool FAILED (flags.at:21)
96: OBJCXX inferred tag FAILED (infer-tag.at:116)
185: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:45)
Explanation: In $PATH I have binaries from GCC 15.2.0, that I built myself,
with configure option
--enable-languages=c,c++,objc,obj-c++,lto,jit,fortran,go,d,m2
i.e. with c++ but without obj-c++.
[dir.tar.gz (application/x-compressed-tar, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Tue, 23 Sep 2025 09:10:03 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
> - Support ML64 (Microsoft Macro Assembler).
Thanks for this feature. I'm using it in GNU libffcall now [1].
Bruno
[1] https://gitweb.git.savannah.gnu.org/gitweb/?p=libffcall.git;a=commitdiff;h=44b8f1b1cf3cb06dc0eb83027a7da34ecb5cb3ef
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Wed, 24 Sep 2025 09:43:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Sep 18, 2025 at 5:05 PM Ileana Dumitrescu <
ileanadumitrescu95 <at> gmail.com> wrote:
> Libtoolers!
>
> The Libtool Team is pleased to announce the release of libtool 2.6.0, a
> alpha release.
>
> GNU Libtool hides the complexity of using shared libraries behind a
> consistent, portable interface. GNU Libtool ships with GNU libltdl, which
> hides the complexity of loading dynamic runtime libraries (modules)
> behind a consistent, portable interface.
>
> Here is the announcement on Savannah:
> https://savannah.gnu.org/news/?id=10814
>
> There have been 68 commits by 19 people in the 43 weeks since 2.5.4.
>
Hello,
I don't know why it didn't get caught earlier, but I got the
following error while testing 2.6.0 in Fedora:
disable-static --disable-sctp
configure: WARNING: unrecognized options: --disable-dependency-tracking
./configure: line 4399: syntax error near unexpected token `)'
./configure: line 4399: `])])'
error: Bad exit status from /var/tmp/rpm-tmp.oz58QM (%build)
When looking at the configure script, the error is here:
# LT_PROG_OBJC
# -----------
])])
# LT_PROG_OBJCXX
# -----------
])])
# LT_PROG_GCJ
# -----------
Which comes from:
# LT_PROG_OBJC
# -----------
AC_DEFUN([LT_PROG_OBJC],
[AC_CHECK_TOOL(OBJC, gcc,)
AC_CHECK_TOOL(GNUSTEP_CONFIG, gnustep-config,)
if test Xgnustep-config = X"$GNUSTEP_CONFIG"; then
test set = "${OBJCFLAGS+set}" || OBJCFLAGS="`gnustep-config
--objc-flags`"
fi
AC_SUBST(OBJCFLAGS)])])[]dnl
])
# LT_PROG_OBJCXX
# -----------
AC_DEFUN([LT_PROG_OBJCXX],
[AC_CHECK_TOOL(OBJCXX, g++,)
AC_CHECK_TOOL(GNUSTEP_CONFIG, gnustep-config,)
if test Xgnustep-config = X"$GNUSTEP_CONFIG"; then
test set = "${OBJCXXFLAGS+set}" || OBJCXXFLAGS="`gnustep-config
--objc-flags`"
fi
AC_SUBST(OBJCXXFLAGS)])])[]dnl
])
Looking at the code, it looks like a copy'n'paste error from the block
after it:
# LT_PROG_GCJ
# -----------
AC_DEFUN([LT_PROG_GCJ],
[m4_ifdef([AC_PROG_GCJ], [AC_PROG_GCJ],
[m4_ifdef([A][M_PROG_GCJ], [A][M_PROG_GCJ],
[AC_CHECK_TOOL(GCJ, gcj,)
test set = "${GCJFLAGS+set}" || GCJFLAGS="-g -O2"
AC_SUBST(GCJFLAGS)])])[]dnl
])
While the "])[]dnl" part is necessary in "LT_PROG_GCJ" due to the m4_ifdef
calls, it is superfluous for "LT_PROG_OBJCXX" and "LT_PROG_OBJC"
May you have a look and fix that ?
For now that's the most obvious problem I found, I'm double checking other
errors.
>
> See the NEWS below for a brief summary.
>
> Thanks to everyone who has contributed!
> The following people contributed changes to this release:
>
> Anthony Mallet (1)
> Bruno Haible (2)
> Christian Feld (1)
> Collin Funk (1)
> Elizabeth Figura (1)
> Evgeny Grin (1)
> Frédéric Bérat (1)
> Gleb Popov (1)
> Ileana Dumitrescu (47)
> Julien ÉLIE (1)
> Karl Berry (1)
> Kirill Makurin (1)
> Manoj Gupta (1)
> Martin Storsjö (1)
> Michael Haubenwallner (2)
> Mintsuki (1)
> Mitch (1)
> Pierre Ossman (2)
> Takashi Yano (1)
>
> Ileana
> [on behalf of the libtool maintainers]
> ==================================================================
>
> Here is the GNU libtool home page:
> https://gnu.org/s/libtool/
>
> Here are the compressed sources:
> https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.gz (2.1MB)
> https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.xz (1.1MB)
>
> Here are the GPG detached signatures:
> https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.gz.sig
> https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.xz.sig
>
> Use a mirror for higher download bandwidth:
> https://www.gnu.org/order/ftp.html
>
> Here are the SHA1 and SHA256 checksums:
>
> File: libtool-2.6.0.tar.gz
> SHA1 sum: 681b41409762acb07232d7af7c289cc8a2f851c9
> SHA256 sum:
> ac9d4b8e072aa20d030d5ae039aba3b52bd7967b09e0c21f91f3e3dc1bbb8755
>
> File: libtool-2.6.0.tar.xz
> SHA1 sum: dff32acab30a9262d19c3559092c2415b6a2b23e
> SHA256 sum:
> 69e6d28ae880fda08e0dc080ef2e38077ea2765a0d84e1afcfcfe1e605c911ac
>
> Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact. First, be sure to download both the .sig file
> and the corresponding tarball. Then, run a command like this:
>
> gpg --verify libtool-2.6.0.tar.gz.sig
>
> The signature should match the fingerprint of the following key:
>
> pub rsa4096 2021-09-23 [SC]
> FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
> uid Ileana Dumitrescu <ileanadumi95 <at> protonmail.com>
> uid Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
>
> If that command fails because you don't have the required public key,
> or that public key has expired, try the following commands to retrieve
> or refresh it, and then rerun the 'gpg --verify' command.
>
> gpg --locate-external-key ileanadumi95 <at> protonmail.com
>
> gpg --recv-keys 6570EA01146F7354
>
> wget -q -O-
> '
> https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1'
>
> | gpg --import -
>
> As a last resort to find the key, you can try the official GNU
> keyring:
>
> wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
> gpg --keyring gnu-keyring.gpg --verify libtool-2.6.0.tar.gz.sig
>
> This release is based on the libtool git repository, available as
>
> git clone https://git.savannah.gnu.org/git/libtool.git
>
> with commit e40fdc22cf727fb885f9df7d9affa827e3253d1c tagged as v2.6.0.
>
> For a summary of changes and contributors, see:
>
> https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.6.0
>
> or run this command from a git-cloned libtool directory:
>
> git shortlog v2.5.4..v2.6.0
>
> This release was bootstrapped with the following tools:
> Autoconf 2.72e
> Automake 1.18.1
> Gnulib 2025-07-29 f0773a994eb75ceeeb44e39145c842044357a1ad
>
> NEWS
>
> * Noteworthy changes in release 2.6.0 (2025-09-18) [alpha]
>
> ** New features:
>
> - Add a new tool, libtool-next-version, to guide users through updating
> library versions.
>
> - Add tagging for Objective-C and Objective-C++, OBJC and OBJCXX.
>
> - Increase 5 digit limit on revision value for libraries to 19 digits,
> which is referencing Unix epoch time in nanoseconds.
>
> - Add configuration options to choose whether to use '-nostdlib' to let
> the compiler frontend decide what standard libraries to link when
> building C++ shared libraries and modules, --enable-cxx-stdlib and
> --disable-cxx-stdlib.
>
> - Allow statically linking GCC and Clang compiler support libraries
> into shared libraries.
>
> - Add linking clang_rt static archives compiler internal libraries by
> their absolute path.
>
> - Set 'mklink' as the symlinking tool for MSVC.
>
> - Pass '--target' architecture flag for Clang.
>
> - Support MSYS and MSYS2 file path conversions.
>
> ** Bug fixes:
>
> - Fix wrongly deduplicated compiler dependencies on linux.
>
> - Fix NetBSD postdeps for shared libraries.
>
> - Fix statically linking dependencies into shared C++ libraries when
> utilizing clang builtins or g++ options like, -static-libstdc++, by
> using a new configuration option, --enable-cxx-stdlib.
>
> - Ensure *-linux-mlibc host matches to mlibc userland rather than
> matching to GNU/Linux and similar userlands.
>
> - Fix hang with cmd.exe in MSYS.
>
> - For MSVC, fix mishandling compiler flags, symlinking, cl.exe '.exp'
> extension collision, symbol names, and numerous testsuite bugs.
>
> - Fix undeclared reference to access on Windows in libltdl.
>
> - Fix flang -Wl flags on FreeBSD.
>
> - Fix reordering '--as-needed' flag.
>
> - Fix libltdl early failures for multi-arch.
>
> ** Changes in supported systems or compilers:
>
> - Support additional Intel OneAPI compilers, 'icx', 'icpx', and 'ifx'.
>
> - Support ML64 (Microsoft Macro Assembler).
>
>
> Enjoy!
>
> --
> Ileana Dumitrescu
>
> GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Mon, 29 Sep 2025 19:07:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 19/09/2025 17:12, Bruno Haible via bug-libtool via Bug reports for
the GNU libtool shared library maintenance tool wrote:
> On Ubuntu 24.04/x86_64 I get these test failures:
>
> 65: passing OBJCXX flags through libtool FAILED (flags.at:21)
> 96: OBJCXX inferred tag FAILED (infer-tag.at:116)
> 185: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:45)
>
> Explanation: In $PATH I have binaries from GCC 15.2.0, that I built myself,
> with configure option
> --enable-languages=c,c++,objc,obj-c++,lto,jit,fortran,go,d,m2
> i.e. with c++ but without obj-c++.
Bruno, thank you for testing the alpha release!
This issue was easy to reproduce, and the fix is in the development
branch now [1].
[1]
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=bbcb9b23c65ec52f4c39858ddd8d50c2818d69bd
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Mon, 29 Sep 2025 19:13:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 24/09/2025 12:41, Frederic Berat wrote:
>
>
> On Thu, Sep 18, 2025 at 5:05 PM Ileana Dumitrescu
> <ileanadumitrescu95 <at> gmail.com <mailto:ileanadumitrescu95 <at> gmail.com>> wrote:
>
> Libtoolers!
>
> The Libtool Team is pleased to announce the release of libtool 2.6.0, a
> alpha release.
>
>
> Hello,
>
> I don't know why it didn't get caught earlier, but I got the
> following error while testing 2.6.0 in Fedora:
>
> disable-static --disable-sctp
> configure: WARNING: unrecognized options: --disable-dependency-tracking
> ./configure: line 4399: syntax error near unexpected token `)'
> ./configure: line 4399: `])])'
> error: Bad exit status from /var/tmp/rpm-tmp.oz58QM (%build)
Thank you for testing in Fedora!
> May you have a look and fix that ?
I am also surprised this did not cause errors in other GNU/Linux
systems, but it has been fixed in the development branch on Savannah now
along with another Objective C++ bug [1].
> For now that's the most obvious problem I found, I'm double checking
> other errors.
I hope for no more bugs, but I happy to fix any more you find :)
[1]
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=bbcb9b23c65ec52f4c39858ddd8d50c2818d69bd
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Mon, 29 Sep 2025 19:16:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 23/09/2025 12:08, Bruno Haible via bug-libtool via Bug reports for
the GNU libtool shared library maintenance tool wrote:
>> - Support ML64 (Microsoft Macro Assembler).
>
> Thanks for this feature. I'm using it in GNU libffcall now [1].
>
> Bruno
>
> [1] https://gitweb.git.savannah.gnu.org/gitweb/?p=libffcall.git;a=commitdiff;h=44b8f1b1cf3cb06dc0eb83027a7da34ecb5cb3ef
I am happy it is already being used. Hopefully you do not find bugs in
this feature :)
Thank you again for testing!
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Tue, 30 Sep 2025 14:06:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Sep 29, 2025 at 9:12 PM Ileana Dumitrescu <
ileanadumitrescu95 <at> gmail.com> wrote:
> On 24/09/2025 12:41, Frederic Berat wrote:
> >
> >
> > On Thu, Sep 18, 2025 at 5:05 PM Ileana Dumitrescu
> > <ileanadumitrescu95 <at> gmail.com <mailto:ileanadumitrescu95 <at> gmail.com>>
> wrote:
> >
> > Libtoolers!
> >
> > The Libtool Team is pleased to announce the release of libtool
> 2.6.0, a
> > alpha release.
> >
> >
> > Hello,
> >
> > I don't know why it didn't get caught earlier, but I got the
> > following error while testing 2.6.0 in Fedora:
> >
> > disable-static --disable-sctp
> > configure: WARNING: unrecognized options: --disable-dependency-tracking
> > ./configure: line 4399: syntax error near unexpected token `)'
> > ./configure: line 4399: `])])'
> > error: Bad exit status from /var/tmp/rpm-tmp.oz58QM (%build)
>
> Thank you for testing in Fedora!
>
> > May you have a look and fix that ?
>
> I am also surprised this did not cause errors in other GNU/Linux
> systems, but it has been fixed in the development branch on Savannah now
> along with another Objective C++ bug [1].
>
> > For now that's the most obvious problem I found, I'm double checking
> > other errors.
>
> I hope for no more bugs, but I happy to fix any more you find :)
>
So far nothing obvious, the failures I've found seem to be problems in the
corresponding packages.
One because it modifies libtool (through sed) and the modifications aren't
compatible anymore (and likely not needed anyway).
The other has "-Werror=maybe-uninitialized" errors that seem to always have
been there but weren't uncovered so far.
>
> [1]
>
> https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=bbcb9b23c65ec52f4c39858ddd8d50c2818d69bd
>
>
Hmm, looks like the fix isn't complete:
+ ./configure --build=x86_64-redhat-linux --host=x86_64-redhat-linux
--program-prefix= --disable-dependency-tracking --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/bin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--includedir=/usr/include/apr-1
--with-installbuilddir=/usr/lib64/apr-1/build --with-devrandom=/dev/urandom
--disable-static --disable-sctp
configure: WARNING: unrecognized options: --disable-dependency-tracking
./configure: line 4403: syntax error near unexpected token `)'
./configure: line 4403: `])'
error: Bad exit status from /var/tmp/rpm-tmp.HQAsTL (%build)
Both `])` needed to be removed, as the closure is done one line later:
I could properly rebuild `apr` with the following (on top of the
development branch):
git diff m4/libtool.m4
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index b758ae5a60ef4454..2f5d0e3ca2c706cd 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -8671,7 +8671,7 @@ AC_DEFUN([LT_PROG_OBJC],
if test Xgnustep-config = X"$GNUSTEP_CONFIG"; then
test set = "${OBJCFLAGS+set}" || OBJCFLAGS="`gnustep-config
--objc-flags`"
fi
- AC_SUBST(OBJCFLAGS)])[]dnl
+ AC_SUBST(OBJCFLAGS)[]dnl
])
# LT_PROG_OBJCXX
@@ -8682,7 +8682,7 @@ AC_DEFUN([LT_PROG_OBJCXX],
if test Xgnustep-config = X"$GNUSTEP_CONFIG"; then
test set = "${OBJCXXFLAGS+set}" || OBJCXXFLAGS="`gnustep-config
--objc-flags`"
fi
- AC_SUBST(OBJCXXFLAGS)])[]dnl
+ AC_SUBST(OBJCXXFLAGS)[]dnl
])
# LT_PROG_GCJ
> --
> Ileana Dumitrescu
>
> GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Tue, 30 Sep 2025 17:29:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 30/09/2025 17:04, Frederic Berat wrote:
> Hmm, looks like the fix isn't complete:
>
> + ./configure --build=x86_64-redhat-linux --host=x86_64-redhat-linux --
> program-prefix= --disable-dependency-tracking --prefix=/usr --exec-
> prefix=/usr --bindir=/usr/bin --sbindir=/usr/bin --sysconfdir=/etc --
> datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --
> libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --
> sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/
> info --includedir=/usr/include/apr-1 --with-installbuilddir=/usr/lib64/
> apr-1/build --with-devrandom=/dev/urandom --disable-static --disable-sctp
> configure: WARNING: unrecognized options: --disable-dependency-tracking
> ./configure: line 4403: syntax error near unexpected token `)'
> ./configure: line 4403: `])'
> error: Bad exit status from /var/tmp/rpm-tmp.HQAsTL (%build)
>
> Both `])` needed to be removed, as the closure is done one line later:
Thank you for testing again. I should have looked at it more before
pushing my "fix". I have committed your changes to the development
branch.
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=53f8ca1d4872dbee1e5a6d0f344df66f0f64f4f9
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Thu, 01 Jan 2026 14:45:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I think something was broken in MSYS2 file path conversion. I attached file which contains one piece from make's output when I tried to build gettext-1.0-pre1 with MSVC. I also encountered this issue when tried to use this alpha release to build ncurses, so this is a bug in this libtool version. Such error massages appear whenever libtool is used for linking.
This effectively made it impossible to test uninstalled DLLs; they simply won't load since path conversion failed and wrapper executables have no idea where to load them from.
There are no such issues when using Cygwin, everything works as expected.
- Kirill Makurin
________________________________
From: bug-libtool-bounces+maiddaisuki=outlook.com <at> gnu.org on behalf of Ileana Dumitrescu
Sent: Friday, September 19, 2025 12:03 AM
To: 79468 <at> debbugs.gnu.org
Cc: autotools-announce <at> gnu.org
Subject: bug#79468: libtool-2.6.0 released [alpha]
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.6.0, a
alpha release.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.
Here is the announcement on Savannah:
https://savannah.gnu.org/news/?id=10814
There have been 68 commits by 19 people in the 43 weeks since 2.5.4.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
The following people contributed changes to this release:
Anthony Mallet (1)
Bruno Haible (2)
Christian Feld (1)
Collin Funk (1)
Elizabeth Figura (1)
Evgeny Grin (1)
Frédéric Bérat (1)
Gleb Popov (1)
Ileana Dumitrescu (47)
Julien ÉLIE (1)
Karl Berry (1)
Kirill Makurin (1)
Manoj Gupta (1)
Martin Storsjö (1)
Michael Haubenwallner (2)
Mintsuki (1)
Mitch (1)
Pierre Ossman (2)
Takashi Yano (1)
Ileana
[on behalf of the libtool maintainers]
==================================================================
Here is the GNU libtool home page:
https://gnu.org/s/libtool/
Here are the compressed sources:
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.gz (2.1MB)
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.xz (1.1MB)
Here are the GPG detached signatures:
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.gz.sig
https://alpha.gnu.org/gnu/libtool/libtool-2.6.0.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
File: libtool-2.6.0.tar.gz
SHA1 sum: 681b41409762acb07232d7af7c289cc8a2f851c9
SHA256 sum:
ac9d4b8e072aa20d030d5ae039aba3b52bd7967b09e0c21f91f3e3dc1bbb8755
File: libtool-2.6.0.tar.xz
SHA1 sum: dff32acab30a9262d19c3559092c2415b6a2b23e
SHA256 sum:
69e6d28ae880fda08e0dc080ef2e38077ea2765a0d84e1afcfcfe1e605c911ac
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify libtool-2.6.0.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa4096 2021-09-23 [SC]
FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid Ileana Dumitrescu <ileanadumi95 <at> protonmail.com>
uid Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key ileanadumi95 <at> protonmail.com
gpg --recv-keys 6570EA01146F7354
wget -q -O-
'https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1'
| gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.6.0.tar.gz.sig
This release is based on the libtool git repository, available as
git clone https://git.savannah.gnu.org/git/libtool.git
with commit e40fdc22cf727fb885f9df7d9affa827e3253d1c tagged as v2.6.0.
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.6.0
or run this command from a git-cloned libtool directory:
git shortlog v2.5.4..v2.6.0
This release was bootstrapped with the following tools:
Autoconf 2.72e
Automake 1.18.1
Gnulib 2025-07-29 f0773a994eb75ceeeb44e39145c842044357a1ad
NEWS
* Noteworthy changes in release 2.6.0 (2025-09-18) [alpha]
** New features:
- Add a new tool, libtool-next-version, to guide users through updating
library versions.
- Add tagging for Objective-C and Objective-C++, OBJC and OBJCXX.
- Increase 5 digit limit on revision value for libraries to 19 digits,
which is referencing Unix epoch time in nanoseconds.
- Add configuration options to choose whether to use '-nostdlib' to let
the compiler frontend decide what standard libraries to link when
building C++ shared libraries and modules, --enable-cxx-stdlib and
--disable-cxx-stdlib.
- Allow statically linking GCC and Clang compiler support libraries
into shared libraries.
- Add linking clang_rt static archives compiler internal libraries by
their absolute path.
- Set 'mklink' as the symlinking tool for MSVC.
- Pass '--target' architecture flag for Clang.
- Support MSYS and MSYS2 file path conversions.
** Bug fixes:
- Fix wrongly deduplicated compiler dependencies on linux.
- Fix NetBSD postdeps for shared libraries.
- Fix statically linking dependencies into shared C++ libraries when
utilizing clang builtins or g++ options like, -static-libstdc++, by
using a new configuration option, --enable-cxx-stdlib.
- Ensure *-linux-mlibc host matches to mlibc userland rather than
matching to GNU/Linux and similar userlands.
- Fix hang with cmd.exe in MSYS.
- For MSVC, fix mishandling compiler flags, symlinking, cl.exe '.exp'
extension collision, symbol names, and numerous testsuite bugs.
- Fix undeclared reference to access on Windows in libltdl.
- Fix flang -Wl flags on FreeBSD.
- Fix reordering '--as-needed' flag.
- Fix libltdl early failures for multi-arch.
** Changes in supported systems or compilers:
- Support additional Intel OneAPI compilers, 'icx', 'icpx', and 'ifx'.
- Support ML64 (Microsoft Macro Assembler).
Enjoy!
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[Message part 2 (text/html, inline)]
[libtool.txt (text/plain, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 15:23:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/01/2026 16:44, Kirill Makurin wrote:
> Hello,
>
> I think something was broken in MSYS2 file path conversion. I attached
> file which contains one piece from make's output when I tried to build
> gettext-1.0-pre1 with MSVC. I also encountered this issue when tried to
> use this alpha release to build ncurses, so this is a bug in this
> libtool version. Such error massages appear whenever libtool is used for
> linking.
>
> This effectively made it impossible to test uninstalled DLLs; they
> simply won't load since path conversion failed and wrapper executables
> have no idea where to load them from.
>
> There are no such issues when using Cygwin, everything works as expected.
Thank you for testing the alpha release! There are two commits related
to the file path conversions for MSYS(2) with and without Cygwin's
cygpath:
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?id=9c1a42a6bb220aa56ad58af8aad0544dab34a710
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?id=0af7b1240395e4da1a3de38b7b399207a254792a
lt_cv_cygpath_installed should be cached for whether cygpath is
installed. If cygpath is not, a check for cmd with one or two slashes
working is cached for the file path conversions, lt_cv_cmd_slashes. If
these are checked and set correctly, there should not be an issue with
MSYS2 and MSVC.
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 15:28:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ileana,
I was thinking maybe the issue is that it does not detect build machine to be msys2? I'm using Msys2's ucrt64 shell for which plain uname produces:
```
MINGW64_NT-10.0-26200
```
compared to plain uname from Msys2's msys2 shell:
```
MSYS_NT-10.0-26200
```
Could it be potential source of this issue?
- Kirill Makurin
________________________________
From: Ileana Dumitrescu
Sent: Saturday, January 3, 2026 12:22 AM
To: Kirill Makurin
Cc: 79468 <at> debbugs.gnu.org
Subject: Re: bug#79468: libtool-2.6.0 released [alpha]
On 01/01/2026 16:44, Kirill Makurin wrote:
> Hello,
>
> I think something was broken in MSYS2 file path conversion. I attached
> file which contains one piece from make's output when I tried to build
> gettext-1.0-pre1 with MSVC. I also encountered this issue when tried to
> use this alpha release to build ncurses, so this is a bug in this
> libtool version. Such error massages appear whenever libtool is used for
> linking.
>
> This effectively made it impossible to test uninstalled DLLs; they
> simply won't load since path conversion failed and wrapper executables
> have no idea where to load them from.
>
> There are no such issues when using Cygwin, everything works as expected.
Thank you for testing the alpha release! There are two commits related
to the file path conversions for MSYS(2) with and without Cygwin's
cygpath:
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?id=9c1a42a6bb220aa56ad58af8aad0544dab34a710
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?id=0af7b1240395e4da1a3de38b7b399207a254792a
lt_cv_cygpath_installed should be cached for whether cygpath is
installed. If cygpath is not, a check for cmd with one or two slashes
working is cached for the file path conversions, lt_cv_cmd_slashes. If
these are checked and set correctly, there should not be an issue with
MSYS2 and MSVC.
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 15:37:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/01/2026 17:27, Kirill Makurin wrote:
> Hi Ileana,
Hi Kirill,
> I was thinking maybe the issue is that it does not detect build machine
> to be msys2? I'm using Msys2's ucrt64 shell for which plain uname produces:
>
> ```
> MINGW64_NT-10.0-26200
> ```
>
> compared to plain uname from Msys2's msys2 shell:
>
> ```
> MSYS_NT-10.0-26200
> ```
>
> Could it be potential source of this issue?
A check for the host and build is done before the values for file
conversion are checked for caching, so that may be your issue..
AS_CASE([$host],
[*-*-mingw* | *-*-windows* | *-*-cygwin*],
[AS_CASE([$build],
[*-*-mingw* | *-*-windows* | *-*-cygwin*],
[AC_MSG_CHECKING([whether cygpath is installed])
Do you have lt_cv_cygpath_installed or lt_cv_cmd_slashes cached?
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 15:44:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Let's see how it goes in configure's output. The build machine is detected correctly...
```
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
```
And a little later...
```
checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-mingw32 format... func_convert_file_msys_to_w32
checking how to convert x86_64-w64-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking whether cygpath is installed... yes
```
I feel like check for cygpath must happen first, isn't it? Any idea what could be wrong?
- Kirill Makurin
________________________________
From: Ileana Dumitrescu
Sent: Saturday, January 3, 2026 12:36 AM
To: Kirill Makurin
Cc: 79468 <at> debbugs.gnu.org
Subject: Re: bug#79468: libtool-2.6.0 released [alpha]
On 02/01/2026 17:27, Kirill Makurin wrote:
> Hi Ileana,
Hi Kirill,
> I was thinking maybe the issue is that it does not detect build machine
> to be msys2? I'm using Msys2's ucrt64 shell for which plain uname produces:
>
> ```
> MINGW64_NT-10.0-26200
> ```
>
> compared to plain uname from Msys2's msys2 shell:
>
> ```
> MSYS_NT-10.0-26200
> ```
>
> Could it be potential source of this issue?
A check for the host and build is done before the values for file
conversion are checked for caching, so that may be your issue..
AS_CASE([$host],
[*-*-mingw* | *-*-windows* | *-*-cygwin*],
[AS_CASE([$build],
[*-*-mingw* | *-*-windows* | *-*-cygwin*],
[AC_MSG_CHECKING([whether cygpath is installed])
Do you have lt_cv_cygpath_installed or lt_cv_cmd_slashes cached?
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 16:06:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/01/2026 17:43, Kirill Makurin wrote:
> Let's see how it goes in configure's output. The build machine is
> detected correctly...
>
> ```
> checking build system type... x86_64-w64-mingw32
> checking host system type... x86_64-w64-mingw32
> ```
>
> And a little later...
>
> ```
> checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-
> mingw32 format... func_convert_file_msys_to_w32
> checking how to convert x86_64-w64-mingw32 file names to toolchain
> format... func_convert_file_msys_to_w32
> checking whether cygpath is installed... yes
> ```
>
> I feel like check for cygpath must happen first, isn't it? Any idea what
> could be wrong?
The cached value for cygpath is checked later in
func_convert_file_msys_to_w32:
```
func_convert_file_msys_to_w32 ()
{
$debug_cmd
func_to_host_file_result=$1
if test -n "$1"; then
if test "Xyes" = "X$cygpath_installed"; then
func_convert_core_msys_to_w32_with_cygpath -w "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_with_cygpath_result
else
func_convert_core_msys_to_w32 "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_result
fi
fi
func_convert_file_check "$1" "$func_to_host_file_result"
}
```
func_convert_core_msys_to_w32_with_cygpath is called to do the
conversion:
```
func_convert_core_msys_to_w32_with_cygpath ()
{
$debug_cmd
# Since MSYS2 is packaged with cygpath, call cygpath in $PATH; no need
# to use LT_CYGPATH in this case.
func_convert_core_msys_to_w32_result=`cygpath "$@" 2>/dev/null |
$SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
if test "$?" -ne 0; then
# on failure, ensure result is empty
func_convert_core_msys_to_w32_result=
fi
}
```
Maybe there is an issue with the result command?
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 16:15:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I copied code to a small `silly.sh`:
```
#!/bin/sh
SED=sed
sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
func_convert_core_msys_to_w32_with_cygpath ()
{
$debug_cmd
# Since MSYS2 is packaged with cygpath, call cygpath in $PATH; no need
# to use LT_CYGPATH in this case.
func_convert_core_msys_to_w32_result=`cygpath "$@" 2>/dev/null |
$SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
if test "$?" -ne 0; then
# on failure, ensure result is empty
func_convert_core_msys_to_w32_result=
fi
}
func_convert_core_msys_to_w32_with_cygpath "$1"
printf %s "$func_convert_core_msys_to_w32_result"
```
Running "./silly.sh /c/Windows" resulted in "\\c\\Windows". I think cygpath invokation is missing -w option :)
- Kirill Makurin
________________________________
From: Ileana Dumitrescu
Sent: Saturday, January 3, 2026 1:05 AM
To: Kirill Makurin
Cc: 79468 <at> debbugs.gnu.org
Subject: Re: bug#79468: libtool-2.6.0 released [alpha]
On 02/01/2026 17:43, Kirill Makurin wrote:
> Let's see how it goes in configure's output. The build machine is
> detected correctly...
>
> ```
> checking build system type... x86_64-w64-mingw32
> checking host system type... x86_64-w64-mingw32
> ```
>
> And a little later...
>
> ```
> checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-
> mingw32 format... func_convert_file_msys_to_w32
> checking how to convert x86_64-w64-mingw32 file names to toolchain
> format... func_convert_file_msys_to_w32
> checking whether cygpath is installed... yes
> ```
>
> I feel like check for cygpath must happen first, isn't it? Any idea what
> could be wrong?
The cached value for cygpath is checked later in
func_convert_file_msys_to_w32:
```
func_convert_file_msys_to_w32 ()
{
$debug_cmd
func_to_host_file_result=$1
if test -n "$1"; then
if test "Xyes" = "X$cygpath_installed"; then
func_convert_core_msys_to_w32_with_cygpath -w "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_with_cygpath_result
else
func_convert_core_msys_to_w32 "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_result
fi
fi
func_convert_file_check "$1" "$func_to_host_file_result"
}
```
func_convert_core_msys_to_w32_with_cygpath is called to do the
conversion:
```
func_convert_core_msys_to_w32_with_cygpath ()
{
$debug_cmd
# Since MSYS2 is packaged with cygpath, call cygpath in $PATH; no need
# to use LT_CYGPATH in this case.
func_convert_core_msys_to_w32_result=`cygpath "$@" 2>/dev/null |
$SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
if test "$?" -ne 0; then
# on failure, ensure result is empty
func_convert_core_msys_to_w32_result=
fi
}
```
Maybe there is an issue with the result command?
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 16:34:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/01/2026 18:14, Kirill Makurin wrote:
> I copied code to a small `silly.sh`:
>
> ```
> #!/bin/sh
>
> SED=sed
> sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
>
> func_convert_core_msys_to_w32_with_cygpath ()
> {
> $debug_cmd
>
> # Since MSYS2 is packaged with cygpath, call cygpath in $PATH; no need
> # to use LT_CYGPATH in this case.
> func_convert_core_msys_to_w32_result=`cygpath "$@" 2>/dev/null |
> $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
> if test "$?" -ne 0; then
> # on failure, ensure result is empty
> func_convert_core_msys_to_w32_result=
> fi
> }
>
> func_convert_core_msys_to_w32_with_cygpath "$1"
> printf %s "$func_convert_core_msys_to_w32_result"
> ```
>
> Running "./silly.sh /c/Windows" resulted in "\\c\\Windows <\\c\
> \Windows>". I think cygpath invokation is missing -w option :)
func_convert_core_msys_to_w32_with_cygpath is called with the -w option,
and cygpath is passed all arguments with $@. It should be okay.
```
func_convert_file_msys_to_w32 ()
{
$debug_cmd
func_to_host_file_result=$1
if test -n "$1"; then
if test "Xyes" = "X$cygpath_installed"; then
func_convert_core_msys_to_w32_with_cygpath -w "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_with_cygpath_result
else
func_convert_core_msys_to_w32 "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_result
fi
fi
func_convert_file_check "$1" "$func_to_host_file_result"
}
```
Here is one of the functions that outputs some of the errors you have:
```
# func_convert_file_check ARG1 ARG2
# Verify that ARG1 (a file name in $build format) was converted to $host
# format in ARG2. Otherwise, emit an error message, but continue (resetting
# func_to_host_file_result to ARG1).
func_convert_file_check ()
{
$debug_cmd
if test -z "$2" && test -n "$1"; then
func_error "Could not determine host file name corresponding to"
func_error " '$1'"
func_error "Continuing, but uninstalled executables may not work."
# Fallback:
func_to_host_file_result=$1
fi
}
```
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 16:43:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I think I see it: `func_convert_core_msys_to_w32_with_cygpath` stores converted filename in `func_convert_core_msys_to_w32_result`, but `func_convert_file_msys_to_w32` sets `func_to_host_file_result` to `func_convert_core_msys_to_w32_with_cygpath_result` after calling `func_convert_core_msys_to_w32_with_cygpath`.
I think you see the issue; to fix it, either:
1. `func_convert_core_msys_to_w32_with_cygpath` should store converted filename in `func_convert_core_msys_to_w32_with_cygpath_result`
2. `func_convert_file_msys_to_w32` should set `func_to_host_file_result` to `func_convert_core_msys_to_w32_result`
- Kirill Makurin
________________________________
From: Ileana Dumitrescu
Sent: Saturday, January 3, 2026 1:33 AM
To: Kirill Makurin
Cc: 79468 <at> debbugs.gnu.org
Subject: Re: bug#79468: libtool-2.6.0 released [alpha]
On 02/01/2026 18:14, Kirill Makurin wrote:
> I copied code to a small `silly.sh`:
>
> ```
> #!/bin/sh
>
> SED=sed
> sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
>
> func_convert_core_msys_to_w32_with_cygpath ()
> {
> $debug_cmd
>
> # Since MSYS2 is packaged with cygpath, call cygpath in $PATH; no need
> # to use LT_CYGPATH in this case.
> func_convert_core_msys_to_w32_result=`cygpath "$@" 2>/dev/null |
> $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
> if test "$?" -ne 0; then
> # on failure, ensure result is empty
> func_convert_core_msys_to_w32_result=
> fi
> }
>
> func_convert_core_msys_to_w32_with_cygpath "$1"
> printf %s "$func_convert_core_msys_to_w32_result"
> ```
>
> Running "./silly.sh /c/Windows" resulted in "\\c\\Windows <\\c\
> \Windows>". I think cygpath invokation is missing -w option :)
func_convert_core_msys_to_w32_with_cygpath is called with the -w option,
and cygpath is passed all arguments with $@. It should be okay.
```
func_convert_file_msys_to_w32 ()
{
$debug_cmd
func_to_host_file_result=$1
if test -n "$1"; then
if test "Xyes" = "X$cygpath_installed"; then
func_convert_core_msys_to_w32_with_cygpath -w "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_with_cygpath_result
else
func_convert_core_msys_to_w32 "$1"
func_to_host_file_result=$func_convert_core_msys_to_w32_result
fi
fi
func_convert_file_check "$1" "$func_to_host_file_result"
}
```
Here is one of the functions that outputs some of the errors you have:
```
# func_convert_file_check ARG1 ARG2
# Verify that ARG1 (a file name in $build format) was converted to $host
# format in ARG2. Otherwise, emit an error message, but continue (resetting
# func_to_host_file_result to ARG1).
func_convert_file_check ()
{
$debug_cmd
if test -z "$2" && test -n "$1"; then
func_error "Could not determine host file name corresponding to"
func_error " '$1'"
func_error "Continuing, but uninstalled executables may not work."
# Fallback:
func_to_host_file_result=$1
fi
}
```
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 18:33:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/01/2026 18:42, Kirill Makurin wrote:
> I think I see it:
> `func_convert_core_msys_to_w32_with_cygpath` stores converted filename
> in `func_convert_core_msys_to_w32_result`, but
> `func_convert_file_msys_to_w32` sets `func_to_host_file_result` to
> `func_convert_core_msys_to_w32_with_cygpath_result` after calling
> `func_convert_core_msys_to_w32_with_cygpath`.
>
> I think you see the issue; to fix it, either:
>
> 1. `func_convert_core_msys_to_w32_with_cygpath` should store converted
> filename in `func_convert_core_msys_to_w32_with_cygpath_result`
> 2. `func_convert_file_msys_to_w32` should set `func_to_host_file_result`
> to `func_convert_core_msys_to_w32_result`
Ah, you are correct! I made a foolish mistake. I committed the changes
to the development branch, and I will cherry-pick it to the master
branch next week if there are no issues.
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=7430a961fa003c3dd69b9f7ab724f7ba74c876ed
Thank you for testing and helping to fix the issue!
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#79468; Package
libtool.
(Fri, 02 Jan 2026 19:01:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 79468 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you for looking into it, hopefully I will find no more issues with this release.
- Kirill Makurin
________________________________
From: Ileana Dumitrescu
Sent: Saturday, January 3, 2026 3:32 AM
To: Kirill Makurin
Cc: 79468 <at> debbugs.gnu.org
Subject: Re: bug#79468: libtool-2.6.0 released [alpha]
On 02/01/2026 18:42, Kirill Makurin wrote:
> I think I see it:
> `func_convert_core_msys_to_w32_with_cygpath` stores converted filename
> in `func_convert_core_msys_to_w32_result`, but
> `func_convert_file_msys_to_w32` sets `func_to_host_file_result` to
> `func_convert_core_msys_to_w32_with_cygpath_result` after calling
> `func_convert_core_msys_to_w32_with_cygpath`.
>
> I think you see the issue; to fix it, either:
>
> 1. `func_convert_core_msys_to_w32_with_cygpath` should store converted
> filename in `func_convert_core_msys_to_w32_with_cygpath_result`
> 2. `func_convert_file_msys_to_w32` should set `func_to_host_file_result`
> to `func_convert_core_msys_to_w32_result`
Ah, you are correct! I made a foolish mistake. I committed the changes
to the development branch, and I will cherry-pick it to the master
branch next week if there are no issues.
https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=7430a961fa003c3dd69b9f7ab724f7ba74c876ed
Thank you for testing and helping to fix the issue!
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[Message part 2 (text/html, inline)]
This bug report was last modified 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.