[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in fu
From: |
Brian Inglis |
Subject: |
bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32) |
Date: |
Wed, 14 Aug 2024 11:40:07 -0600 |
User-agent: |
Mozilla Thunderbird |
This is not a duplicate of that path bug.
The `cmd //c ...` is not a path, which under Windows would contain backslashes
'\', it is an invocation of the Windows console command line shell `cmd`.
Those slashes are Windows console shell command line option switch characters
'/', with `cmd /c ...` meant to be equivalent to `sh -c ...`.
It includes an invalid Windows options switch '//c', which results in the
Windows `cmd` shell being invoked as an interactive console shell, as if invoked
with the '/k' switch, but ignoring any provided command string, hanging builds!
For example, under Cygwin under Windows, I can reproduce this failure:
$ cmd //c dir
Microsoft Windows [Version 10.0.19045.4651]
(c) Microsoft Corporation. All rights reserved.
C:\...>exit
$ cmd dir
Microsoft Windows [Version 10.0.19045.4651]
(c) Microsoft Corporation. All rights reserved.
C:\...>exit
$ cmd /c dir
Volume in drive C is SYSSW932GB
Volume Serial Number is EE45-4341
Directory of C:\usr\local\cygwin64\usr\src\cygport\ca
2024-08-14 09:55 <DIR> .
2024-08-14 09:55 <DIR> ..
2024-08-14 01:14 <DIR> .git
2022-09-06 01:28 <DIR> .github
2022-09-06 01:28 55 .gitignore
2022-09-06 01:28 103 .gitmodules
2022-09-06 01:28 478 AUTHORS
2024-05-07 01:50 <DIR> bin
2024-08-14 01:13 1,137 COMMIT_MSG
2022-09-06 01:28 35,149 COPYING
2022-09-06 01:28 23,006 COPYING-DOCS
2024-08-14 01:10 <DIR> cygclass
2024-05-07 01:50 7,981 cygport.spec
2024-05-07 01:50 <DIR> data
2023-11-20 22:26 <DIR> doc
2024-05-07 01:50 <DIR> lib
2024-05-07 01:50 655 meson.build
2022-09-06 01:28 61 meson_options.txt
2024-05-07 01:50 41,198 NEWS
2024-05-07 01:50 10,295 README
2023-11-20 22:26 <DIR> testsuite
2022-09-06 01:28 335 TODO
2022-09-06 01:28 <DIR> tools
12 File(s) 120,453 bytes
11 Dir(s) 403,840,393,216 bytes free
$ sh --c
sh: 0: Illegal option --
$ echo $SHELL
/bin/bash
$
As shown above, if you invoke the equivalent `sh --c`, the shell complains about
the invalid option and exits, and does not hang around as an interactive shell,
but the Windows console command line shell is more "helpful"!
Even if you put that invalid Windows console command line inside a Windows
"batch" `cmd` script, it hangs the script at the interactive console command
line, until `exit` is typed interactively:
$ head t.cmd
cmd //c dir
exit
$ llgo t.cmd
-rwxr-xr-x 1 12 Aug 14 11:21 t.cmd*
$ cmd /c t.cmd
C:\usr\local\cygwin64\usr\src\cygport\ca>cmd //c dir
Microsoft Windows [Version 10.0.19045.4651]
(c) Microsoft Corporation. All rights reserved.
C:\usr\local\cygwin64\usr\src\cygport\ca>exit <<<--- typed
C:\usr\local\cygwin64\usr\src\cygport\ca>exit
$
I hope that better explains the issue, and am surprised that many folks working
on Windows (cross-) builds do not have a better handle on the build environment,
and its issues, as these communication issues often recur.
I characterize that personally as "Shit I shouldn't need to know!", but I have
had to, to do stuff like porting shell scripts to Windows `cmd` scripts and
utilities, for business continuity and disaster recovery on user's home PCs. ;^>
If you don't like running Windows, you can always run Cygwin under Wine under
Linux, as the two projects interoperate and cooperate, also with Mingw64 and
Msys2, so you can get wonderfully lost, as with running under multi-level VMs.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
On 2024-08-14 09:58, GNU bug Tracking System wrote:
Your bug report
#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
which was filed against the libtool package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to49246@debbugs.gnu.org.
-- 49246: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246 GNU Bug Tracking
System Contact help-debbugs@gnu.org with problems
ForwardedMessage.eml
Subject:
Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
From:
Ileana Dumitrescu <ileanadumitrescu95@gmail.com>
Date:
2024-08-14, 09:56
To:
49246-done@debbugs.gnu.org
This looks like a duplicate of bug#10949:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949
It explains why the double slash is intentional and where in the
documentation to look to better understand cross-building.
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
ForwardedMessage.eml
Subject:
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
From:
Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Date:
2021-06-27, 14:19
To:
bug-libtool@gnu.org, Libtool Patches <libtool-patches@gnu.org>
BCC:
Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Problem reported by a downstream Cygwin user inadvertently
misconfiguring a package cross-build with mingw toolchain:
libtool with mingw hangs building openocd in
func_convert_core_msys_to_w32:
https://cygwin.com/pipermail/cygwin/2021-June/248791.html
The issue exists in libtool build-aux/ltmain.in line 963 in
func_convert_core_msys_to_w32 Windows subshell command:
( cmd //c echo "$1" )
see:
https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n963
where the switch char "/" is duplicated, so instead of executing one
command in the Windows subshell context, a subshell is spawned and hangs
until manually exited e.g.:
$ cmd //c echo "$1"
Microsoft Windows [Version 10.0.19042.985]
(c) Microsoft Corporation. All rights reserved.
C:\...>exit
$
The patch merely removes the extraneous duplicated switch char "/".
As the patch is trivial, no copyright assignemnt should be required.
---
build-aux/ltmain.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
0001-libtool-with-mingw-hangs-in-func_convert_core_msys_to_w32.patch
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b3700347d5..4b8088903740 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -960,7 +960,7 @@ func_convert_core_msys_to_w32 ()
$debug_cmd
# awkward: cmd appends spaces to result
- func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null |
+ func_convert_core_msys_to_w32_result=`( cmd /c echo "$1" ) 2>/dev/null |
$SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
}
#end: func_convert_core_msys_to_w32
- bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32, Ileana Dumitrescu, 2024/08/14
- Message not available
- Message not available
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32),
Brian Inglis <=
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Ileana Dumitrescu, 2024/08/14
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian . Inglis, 2024/08/14
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Ileana Dumitrescu, 2024/08/15
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Nick Bowler, 2024/08/15
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Ileana Dumitrescu, 2024/08/16
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian . Inglis, 2024/08/17
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Nick Bowler, 2024/08/17
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian . Inglis, 2024/08/17