GNU bug report logs -
#49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49246 in the body.
You can then email your comments to 49246 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Sun, 27 Jun 2021 23:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Brian Inglis <Brian.Inglis <at> SystematicSW.ab.ca>:
New bug report received and forwarded. Copy sent to
bug-libtool <at> gnu.org.
(Sun, 27 Jun 2021 23:09: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)]
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 (text/x-patch, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Mon, 28 Jun 2021 12:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 49246 <at> debbugs.gnu.org (full text, mbox):
I can now see what may be a prior duplicate report under:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949
responding that //c is deliberate so MSYS does not try to convert a
posix path, such that in the Cygwin Mingw build case, the response may
be "Don't Do That"!
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
Reply sent
to
Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>:
You have taken responsibility.
(Wed, 14 Aug 2024 15:58:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Brian Inglis <Brian.Inglis <at> SystematicSW.ab.ca>:
bug acknowledged by developer.
(Wed, 14 Aug 2024 15:58:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 49246-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Wed, 14 Aug 2024 17:41:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 49246 <at> debbugs.gnu.org (full text, mbox):
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 <at> debbugs.gnu.org.
>
> -- 49246: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246 GNU Bug Tracking
> System Contact help-debbugs <at> 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 <at> gmail.com>
> Date:
> 2024-08-14, 09:56
>
> To:
> 49246-done <at> 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 <at> SystematicSW.ab.ca>
> Date:
> 2021-06-27, 14:19
>
> To:
> bug-libtool <at> gnu.org, Libtool Patches <libtool-patches <at> gnu.org>
> BCC:
> Brian Inglis <Brian.Inglis <at> 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
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 14 Aug 2024 17:59:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Wed, 14 Aug 2024 18:13:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 49246 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Brian,
On 14/08/2024 20:40, Brian Inglis wrote:
> 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.
>
It seems I misunderstood the previous email that made it seem like this
was identified as a duplicate? I have reopened the bug, and I will look
into testing it.
--
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#49246; Package
libtool.
(Wed, 14 Aug 2024 18:39:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 49246 <at> debbugs.gnu.org (full text, mbox):
On 2024-08-14 12:10, Ileana Dumitrescu wrote:
> Hi Brian,
>
> On 14/08/2024 20:40, Brian Inglis wrote:
>> 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.
>>
>
> It seems I misunderstood the previous email that made it seem like this
> was identified as a duplicate? I have reopened the bug, and I will look
> into testing it.
Thank you very much, that would be greatly appreciated by our tool users.
--
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
Reply sent
to
Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>:
You have taken responsibility.
(Thu, 15 Aug 2024 15:25:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Brian Inglis <Brian.Inglis <at> SystematicSW.ab.ca>:
bug acknowledged by developer.
(Thu, 15 Aug 2024 15:25:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 49246-done <at> debbugs.gnu.org (full text, mbox):
Hi Brian,
On 14/08/2024 21:37, Brian.Inglis <at> SystematicSW.ab.ca wrote:
> On 2024-08-14 12:10, Ileana Dumitrescu wrote:
>> Hi Brian,
>>
>> On 14/08/2024 20:40, Brian Inglis wrote:
>>> 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.
>>>
>>
>> It seems I misunderstood the previous email that made it seem like this
>> was identified as a duplicate? I have reopened the bug, and I will look
>> into testing it.
>
> Thank you very much, that would be greatly appreciated by our tool users.
I applied your patch through the existing testing framework and found no
issues, but I do not think I have the configuration setup to properly
test this bug. Looking through your explanation of the issue, I think
it is okay to apply the patch:
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=37b7146c13a62a46273fd1478e6ad8fe42f9b551
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Thu, 15 Aug 2024 19:52:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 49246 <at> debbugs.gnu.org (full text, mbox):
On 2024-08-15 11:22, Ileana Dumitrescu wrote:
> I applied your patch through the existing testing framework and found no
> issues, but I do not think I have the configuration setup to properly
> test this bug. Looking through your explanation of the issue, I think
> it is okay to apply the patch:
>
> https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=37b7146c13a62a46273fd1478e6ad8fe42f9b551
Unless I'm very confused by the duplicate/not duplicate discussion this
cannot possibly be the right thing to do for MSYS.
The MSYS shell automatically translates arguments to external commands
that look like absolute POSIX filenames into absolute Windows filenames.
This is problematic for VMS/DOS-like commands which usually have options
starting with a slash, so MSYS allows you to call these by using two
slashes (which it substitutes with a single slash before running the
program).
If you run the following command in the MSYS shell:
cmd /c echo /home
the command that actually gets run by Windows is:
cmd C:/ echo C:/msys/home (or similar)
which is bogus and just launches an interactive cmd prompt. It must be:
cmd //c echo /home
which prints C:/msys/home as expected.
Cheers,
Nick
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Fri, 16 Aug 2024 14:40:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 49246 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 15/08/2024 22:49, Nick Bowler wrote:
> On 2024-08-15 11:22, Ileana Dumitrescu wrote:
>> I applied your patch through the existing testing framework and found no
>> issues, but I do not think I have the configuration setup to properly
>> test this bug. Looking through your explanation of the issue, I think
>> it is okay to apply the patch:
>>
>> https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=37b7146c13a62a46273fd1478e6ad8fe42f9b551
>
> Unless I'm very confused by the duplicate/not duplicate discussion this
> cannot possibly be the right thing to do for MSYS.
>
> The MSYS shell automatically translates arguments to external commands
> that look like absolute POSIX filenames into absolute Windows filenames.
>
> This is problematic for VMS/DOS-like commands which usually have options
> starting with a slash, so MSYS allows you to call these by using two
> slashes (which it substitutes with a single slash before running the
> program).
>
> If you run the following command in the MSYS shell:
>
> cmd /c echo /home
>
> the command that actually gets run by Windows is:
>
> cmd C:/ echo C:/msys/home (or similar)
>
> which is bogus and just launches an interactive cmd prompt. It must be:
>
> cmd //c echo /home
>
> which prints C:/msys/home as expected.
>
> Cheers,
> Nick
After re-reading the bug report, I wonder if Brian's configuration is
setup incorrectly to cause this failure? Whether you are building on
MSYS for a MSYS host or building on MSYS for a Cygwin host, the same
format has been used: 'cmd //c ...'. The build environment should be
handling the command parsing at this point, correct? If MSYS is
executing the command, Brian would not have had hanging builds though. I
am not sure whether a new check should be added to libtool to handle the
type of configuration Brian seems to have or if something in Brian's
build is not configured properly.
I think I will revert the patch in development, but I will wait for
some feedback from those who can test this.
--
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#49246; Package
libtool.
(Sat, 17 Aug 2024 14:14:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 49246 <at> debbugs.gnu.org (full text, mbox):
On 2024-08-15 13:49, Nick Bowler wrote:
> On 2024-08-15 11:22, Ileana Dumitrescu wrote:
>> I applied your patch through the existing testing framework and found no
>> issues, but I do not think I have the configuration setup to properly
>> test this bug. Looking through your explanation of the issue, I think
>> it is okay to apply the patch:
>>
>> https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=37b7146c13a62a46273fd1478e6ad8fe42f9b551
>
> Unless I'm very confused by the duplicate/not duplicate discussion this
> cannot possibly be the right thing to do for MSYS.
>
> The MSYS shell automatically translates arguments to external commands
> that look like absolute POSIX filenames into absolute Windows filenames.
>
> This is problematic for VMS/DOS-like commands which usually have options
> starting with a slash, so MSYS allows you to call these by using two
> slashes (which it substitutes with a single slash before running the
> program).
VMS is yet another different kettle of fish with its own .com scripts!
> If you run the following command in the MSYS shell:
> cmd /c echo /home
> the command that actually gets run by Windows is:
> cmd C:/ echo C:/msys/home (or similar)
> which is bogus and just launches an interactive cmd prompt. It must be:
> cmd //c echo /home
> which prints C:/msys/home as expected.
The same libtool can be run from a Cygwin, Msys2/Mingw64, or Msys/Mingw/32
shell: as far as I know such recent shells are derived from Cygwin or upstream
dash/mksh/tcsh sources, and I do not remember any such Windows switch or drive
mangling, unless by ancient legacy original Mingw/32/Msys shells, which are
unlikely to still be in use nowadays, as development and support likely long
moved to their successors.
The config or runtime should be checking if any of these assumptions still hold
in the shell interfaces, and also maybe use the supported shells rather than
cmd, or is it just that the build environment is supported more by Windows than
Unix devs?
I am still often surprised by how much legacy junk is in packages, based on
assumptions about how Cygwin (Msys2, Mingw64, etc.) was many versions and
decades ago, when it was less POSIX (and Linux, BSD, and Solaris) compliant and
more Win32 compliant than now.
--
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
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Sat, 17 Aug 2024 14:47:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 49246 <at> debbugs.gnu.org (full text, mbox):
On 2024-08-17 10:12, Brian.Inglis <at> SystematicSW.ab.ca wrote:
> The same libtool can be run from a Cygwin, Msys2/Mingw64, or
> Msys/Mingw/32 shell: as far as I know such recent shells are derived
> from Cygwin or upstream dash/mksh/tcsh sources, and I do not remember
> any such Windows switch or drive mangling, unless by ancient legacy
> original Mingw/32/Msys shells, which are unlikely to still be in use
> nowadays, as development and support likely long moved to their
> successors.
It works just as I described in a reasonably recent version of MSYS2 (I
have version 20240113 installed) on a current version of Windows:
$ cmd //c echo /home
C:/msys64/home
$ cmd /c echo /home
Microsoft Windows [Version 10.0.22621.3880]
(c) Microsoft Corporation, All rights reserved.
C:\msys64\home\nbowler>
Virtually identical behaviour is observed with a very old MSYS 1.0.8
installation on Windows 98:
$ cmd //c echo /home
D:/MSYS/1.0/home
$ cmd /c echo /home
Invalid switch
Too many parameters
Too many parameters
Invalid switch
Invalid switch
Invalid switch
Microsoft(R) Windows 98
(C)Copyright Microsoft Corp 1989-1999.
D:\DJGPP\home>
Cheers,
Nick
Information forwarded
to
bug-libtool <at> gnu.org:
bug#49246; Package
libtool.
(Sat, 17 Aug 2024 19:17:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 49246 <at> debbugs.gnu.org (full text, mbox):
On 2024-08-17 08:44, Nick Bowler wrote:
> On 2024-08-17 10:12, Brian.Inglis <at> SystematicSW.ab.ca wrote:
>> The same libtool can be run from a Cygwin, Msys2/Mingw64, or
>> Msys/Mingw/32 shell: as far as I know such recent shells are derived
>> from Cygwin or upstream dash/mksh/tcsh sources, and I do not remember
>> any such Windows switch or drive mangling, unless by ancient legacy
>> original Mingw/32/Msys shells, which are unlikely to still be in use
>> nowadays, as development and support likely long moved to their
>> successors.
>
> It works just as I described in a reasonably recent version of MSYS2 (I
> have version 20240113 installed) on a current version of Windows:
> $ cmd //c echo /home
> C:/msys64/home
> $ cmd /c echo /home
> Microsoft Windows [Version 10.0.22621.3880]
> (c) Microsoft Corporation, All rights reserved.
> C:\msys64\home\nbowler>
> Virtually identical behaviour is observed with a very old MSYS 1.0.8
> installation on Windows 98:
> $ cmd //c echo /home
> D:/MSYS/1.0/home
> $ cmd /c echo /home
> Invalid switch
> Too many parameters
> Too many parameters
> Invalid switch
> Invalid switch
> Invalid switch
> Microsoft(R) Windows 98
> (C)Copyright Microsoft Corp 1989-1999.
> D:\DJGPP\home>
Those kinds of issues could be why I skipped Msys/2/Mingw/32, and disliking
AT&T, Sun, 386BSD, and MKS buffer and size limitations, stuck with my own GNU
ports and DJGPP, until I got a Windows version that ran Cygwin!
In one part of the wiki it says to skip conversion use:
MSYS2_ARG_CONV_EXCL=*
so is the the best advice for our user?
--
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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 15 Sep 2024 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 50 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.