bug-libtool
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]