Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Dietmar May]

Thanks for submitting the bug report.

> I can now see what may be a duplicate report under:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949
>
> responding that //c is deliberate so MSYS does not convert a posix path,
> so in the Cygwin Mingw build case, the response may be "Don't Do That"! 

I just re-installed msys2 and tried a few things, with interesting result.

First, "ls /usr//bin" as well as "ls /usr/////bin" complete successfully 
under both cygwin and msys2, demonstrating slash compaction.

However, "ls //usr/bin" hangs, as both apparently evaluate the leading 
// as a server path.

For testing libtool's construct, I tried:

$ cmd //c echo hello
hello

which works, and this, which doesn't:

$ cmd /c echo hello

Microsoft Windows [Version 10.0.blah]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\myname>

Interestingly,

ls //c

hangs under msys2 (as well as cygwin),

whereas

cmd //c

does not; so it almost seems like msys2 has a hack to recognize that 
cmd.exe is being invoked ...

However, both of the following also complete successfully under msys2, 
WITHOUT the double-slash hack:

$ cmd /c "echo hello"
hello

$ cmd "/c" "echo hello"
hello

Both seem preferable to bad syntax.

Of course, there's always the question of why libtool is using cmd.exe 
instead of /bin/echo, which seems to work just fine ...

$ /bin/echo "hello world"
hello world

> On 2021-06-27 14:23, Brian Inglis wrote:
>>> Which you don't need to change if you configure properly, as JonY 
>>> replied on the list to your earlier post:
>>
>>>> On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
>>>>> Don't set --build, you are building on Cygwin, not MSYS.
>>
>>> Jonathan Yong is correct - removing --build allows make to complete 
>>> without error using the unmodified ltmain.sh > There's still the 
>>> issue of generating a call to cmd.exe with an
>>> invalid switch (//c), which will cause it to hang indefinitely if
>>> ever invoked.
>>  > The risk of breaking anything by fixing this seems like nil.
>>
>> The issue exists in the package libtool upstream:
>>
>> https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n963 
>>
>>
>> I submitted a bug report with link to this thread and patch to the 
>> upstream package maintainers; I will post any responses received.
>

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[René Berber]

On 6/28/2021 8:56 AM, Dietmar May via Cygwin wrote:

> Thanks for submitting the bug report.
> 
>> I can now see what may be a duplicate report under:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949
>>
>> responding that //c is deliberate so MSYS does not convert a posix path,
>> so in the Cygwin Mingw build case, the response may be "Don't Do That"! 
> 
> I just re-installed msys2 and tried a few things, with interesting result.
> 
> First, "ls /usr//bin" as well as "ls /usr/////bin" complete successfully 
> under both cygwin and msys2, demonstrating slash compaction.
> 
> However, "ls //usr/bin" hangs, as both apparently evaluate the leading 
> // as a server path.

Well documented here:

https://cygwin.com/cygwin-ug-net/using.html#unc-paths

> For testing libtool's construct, I tried:
> 
> $ cmd //c echo hello
> hello
> 
> which works, and this, which doesn't:
> 
> $ cmd /c echo hello
> 
> Microsoft Windows [Version 10.0.blah]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\msys64\home\myname>

Your example seems to be inverted, the first form doesn't work, the 
second does with the same results you show (but inverted).

It would be better if you document how you executed those commands, 
we're assuming a mintty terminal running a bash shell, but I haven't 
followed all your messages and it might be a cmd window; results 
shouldn't change anyway, but for completeness sake.

> Interestingly,
> 
> ls //c
> 
> hangs under msys2 (as well as cygwin),

Expected as the documentation link describes, //c is taken as a path to 
a server, you already knew that.

> whereas
> 
> cmd //c
> 
> does not; so it almost seems like msys2 has a hack to recognize that 
> cmd.exe is being invoked ...

No, wrong, cmd is getting an argument which it interprets as it seems 
fit, no hack there.  The same applies to the ls example before, ls 
receives an argument which is expected to be a path, nothing strange.

> However, both of the following also complete successfully under msys2, 
> WITHOUT the double-slash hack:
> 
> $ cmd /c "echo hello"
> hello
> 
> $ cmd "/c" "echo hello"
> hello
> 
> Both seem preferable to bad syntax.
> 
> Of course, there's always the question of why libtool is using cmd.exe 
> instead of /bin/echo, which seems to work just fine ...
> 
> $ /bin/echo "hello world"
> hello world
-- 
R.Berber

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Evgeny Grin]

[-- Attachment #1.1.1: Type: text/plain, Size: 5971 bytes --]

Sorry for necroreply. Just to keen in history records.

When starting any program under MSYS (and MSYS2), the MSYS[2] checks 
whether the lunched program is linked with msys-*.dll.
If program is linked with this DLL then the program expects POSIX-like 
environment so no path translation is performed.
If program is not linked with this DLL then the program is native 
Windows binary, which expects native Windows paths. In such case the 
MSYS[2] scans all arguments for POSIX-like paths and converts all of 
them to Windows native paths. The problem is that all Windows drives are 
mounted as single letter in the root so the path like "/d/path/file" 
should be translated into "D:/path/file", while "/c" is translated into 
"C:/"
To prevent this translation double slash could be used. Double slash is 
replaced with single slash.

Examples:

------------------------
MSYS ~
$ cmd /c echo "/c"
Microsoft Windows [Version 10.0.19045.3208]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\user>exit

MSYS ~
$ cmd //c echo "/c"
C:/

MSYS ~
$ cmd //c echo "//c"
/c

MSYS ~
$ cmd //c echo "///c"
//c

MSYS ~
$ echo.exe "/c"
/c

MSYS ~
$ echo.exe "//c"
//c
------------------------
"echo.exe" is Msys program. cmd is not Msys program.

-- 
Evgeny


On 28.06.2021 19:29, Dietmar May via Cygwin wrote:
>> >/$ cmd //c echo hello />/hello />//>/which works, and this, which 
>> doesn't: />//>/$ cmd /c echo hello />//>/Microsoft Windows [Version 
>> 10.0.blah] />/(c) Microsoft Corporation. All rights reserved. 
>> />//>/C:\msys64\home\myname> /
>> Your example seems to be inverted, the first form doesn't work, the
>> second does with the same results you show (but inverted).
>>
>> It would be better if you document how you executed those commands,
>> we're assuming a mintty terminal running a bash shell, but I haven't
>> followed all your messages and it might be a cmd window; results
>> shouldn't change anyway, but for completeness sake.
> 
> More details for you, then:
> 
>  >/I just re-installed msys2 and tried a few things, with interesting 
> result. /
> 
> I install msys2-x86_64-20210604.exe (downloaded last week) from the 
> msys2 website, and accept all defaults during installation, including 
> the "run msys2 now" on the final installation screen (which, yes, opens 
> a mintty terminal running msys2's bash shell). All commands are executed 
> in that same mintty window immediately following a fresh installation.
> 
> So here is the output, cut-and-pasted from that mintty terminal:
> 
> dietmar@laptop MSYS ~
> $ cmd //c echo hello
> hello
> 
> dietmar@laptop MSYS ~
> $ cmd /c echo hello
> Microsoft Windows [Version 10.0.19043.1055]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\msys64\home\dietmar>
> 
> As you can see, the first form DOES INDEED work, and the second does 
> not. Why not try it yourself? You will likely have the same results.
> 
>> No, wrong, cmd is getting an argument which it interprets as it seems
>> fit, no hack there.  The same applies to the ls example before, ls
>> receives an argument which is expected to be a path, nothing strange.
> To find out what cmd is really doing, I believe the authoritative answer 
> would be given by Microsoft's Command Prompt:
> 
> Microsoft Windows [Version 10.0.19043.1055]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\Users\dietmar>cmd //c echo hello
> Microsoft Windows [Version 10.0.19043.1055]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\Users\dietmar>exit
> 
> C:\Users\dietmar>
> 
> Here we see that cmd.exe //c starts a subshell, rather than executing a 
> single command.
> 
> However, in msys2's mintty/bash window, that same syntax works differently:
> 
> dietmar@laptop MSYS ~
> $ cmd //c echo hello
> hello
> 
> dietmar@laptop MSYS ~
> $ cmd ///c echo hello
> Microsoft Windows [Version 10.0.19043.1055]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\msys64\home\dietmar>exit
> exit
> 
> dietmar@laptop MSYS ~
> $ cmd ////c echo hello
> hello
> 
> dietmar@laptop MSYS ~
> $ cmd //////c echo hello
> hello
> 
> dietmar@laptop MSYS ~
> $ cmd ////////c echo hello
> hello
> 
> dietmar@laptop MSYS ~
> $ cmd /////////c echo hello
> Microsoft Windows [Version 10.0.19043.1055]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\msys64\home\dietmar>exit
> exit
> 
> dietmar@laptop MSYS ~
> $
> 
> It seems evident that msys2 is performing slash escaping - ie. 2 
> consecutive slashes are consolidated into a single slash (rather like 
> quote escaping in various languages - eg. SQL, CSV, C#, YAML) 
> recursively (ie. repeatedly) during argument evaluation.
> 
> Again, why not simply change this to a form that works without the slash 
> hackery?
> 
> dietmar@laptop MSYS ~
> $ cmd /c "echo hello"
> hello
> 
>> >/Interestingly, />//>/ls //c />//>/hangs under msys2 (as well as 
>> cygwin), /
>> Expected as the documentation link describes, //c is taken as a path to
>> a server, you already knew that.
>>
>> >/whereas />//>/cmd //c />//>/does not; so it almost seems like msys2 
>> has a hack to recognize that />/cmd.exe is being invoked ... /
>> No, wrong, cmd is getting an argument which it interprets as it seems
>> fit, no hack there.  The same applies to the ls example before, ls
>> receives an argument which is expected to be a path, nothing strange.
>>
>> >/However, both of the following also complete successfully under 
>> msys2, />/WITHOUT the double-slash hack: />//>/$ cmd /c "echo hello" 
>> />/hello />//>/$ cmd "/c" "echo hello" />/hello />//>/Both seem 
>> preferable to bad syntax. />//>/Of course, there's always the question 
>> of why libtool is using cmd.exe />/instead of /bin/echo, which seems 
>> to work just fine ... />//>/$ /bin/echo "hello world" />/hello world 
>> /-- R.Berber
> 
> 

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4085 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Jonathan Yong]

On 6/28/21 4:29 PM, Dietmar May via Cygwin wrote:
> It seems evident that msys2 is performing slash escaping - ie. 2 
> consecutive slashes are consolidated into a single slash (rather like 
> quote escaping in various languages - eg. SQL, CSV, C#, YAML) 
> recursively (ie. repeatedly) during argument evaluation.
> 
> Again, why not simply change this to a form that works without the slash 
> hackery?
> 

MSYS2 is NOT MSYS NOR a continuation, it is developed by separate groups.

MSYS was based off an ancient Cygwin fork from the 1.3 days, while MSYS2 
started life from Cygwin 1.7.

MSYS has been around for a long time, and is heavily used by the 
original mingw.org mingw distribution. Libtool is catered to work with 
MSYS simply because it has been around far longer than MSYS2.

I'd say if anything, libtool needs to check if it is on MSYS2 or MSYS 
and then work appropriately. MSYS2 should be treated as close as 
possible to Cygwin.

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Dietmar May]

> >/$ cmd //c echo hello />/hello />//>/which works, and this, which doesn't: />//>/$ cmd /c echo hello />//>/Microsoft Windows [Version 10.0.blah] />/(c) Microsoft Corporation. All rights reserved. />//>/C:\msys64\home\myname> /
> Your example seems to be inverted, the first form doesn't work, the
> second does with the same results you show (but inverted).
>
> It would be better if you document how you executed those commands,
> we're assuming a mintty terminal running a bash shell, but I haven't
> followed all your messages and it might be a cmd window; results
> shouldn't change anyway, but for completeness sake.

More details for you, then:

 >/I just re-installed msys2 and tried a few things, with interesting 
result. /

I install msys2-x86_64-20210604.exe (downloaded last week) from the 
msys2 website, and accept all defaults during installation, including 
the "run msys2 now" on the final installation screen (which, yes, opens 
a mintty terminal running msys2's bash shell). All commands are executed 
in that same mintty window immediately following a fresh installation.

So here is the output, cut-and-pasted from that mintty terminal:

dietmar@laptop MSYS ~
$ cmd //c echo hello
hello

dietmar@laptop MSYS ~
$ cmd /c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\dietmar>

As you can see, the first form DOES INDEED work, and the second does 
not. Why not try it yourself? You will likely have the same results.

> No, wrong, cmd is getting an argument which it interprets as it seems
> fit, no hack there.  The same applies to the ls example before, ls
> receives an argument which is expected to be a path, nothing strange.
To find out what cmd is really doing, I believe the authoritative answer 
would be given by Microsoft's Command Prompt:

Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\Users\dietmar>cmd //c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\Users\dietmar>exit

C:\Users\dietmar>

Here we see that cmd.exe //c starts a subshell, rather than executing a 
single command.

However, in msys2's mintty/bash window, that same syntax works differently:

dietmar@laptop MSYS ~
$ cmd //c echo hello
hello

dietmar@laptop MSYS ~
$ cmd ///c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\dietmar>exit
exit

dietmar@laptop MSYS ~
$ cmd ////c echo hello
hello

dietmar@laptop MSYS ~
$ cmd //////c echo hello
hello

dietmar@laptop MSYS ~
$ cmd ////////c echo hello
hello

dietmar@laptop MSYS ~
$ cmd /////////c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\dietmar>exit
exit

dietmar@laptop MSYS ~
$

It seems evident that msys2 is performing slash escaping - ie. 2 
consecutive slashes are consolidated into a single slash (rather like 
quote escaping in various languages - eg. SQL, CSV, C#, YAML) 
recursively (ie. repeatedly) during argument evaluation.

Again, why not simply change this to a form that works without the slash 
hackery?

dietmar@laptop MSYS ~
$ cmd /c "echo hello"
hello

> >/Interestingly, />//>/ls //c />//>/hangs under msys2 (as well as cygwin), /
> Expected as the documentation link describes, //c is taken as a path to
> a server, you already knew that.
>
> >/whereas />//>/cmd //c />//>/does not; so it almost seems like msys2 has a hack to recognize that />/cmd.exe is being invoked ... /
> No, wrong, cmd is getting an argument which it interprets as it seems
> fit, no hack there.  The same applies to the ls example before, ls
> receives an argument which is expected to be a path, nothing strange.
>
> >/However, both of the following also complete successfully under msys2, />/WITHOUT the double-slash hack: />//>/$ cmd /c "echo hello" />/hello />//>/$ cmd "/c" "echo hello" />/hello />//>/Both seem preferable to bad syntax. />//>/Of course, there's always the question of why libtool is using cmd.exe />/instead of /bin/echo, which seems to work just fine ... />//>/$ /bin/echo "hello world" />/hello world /-- 
> R.Berber

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Brian Inglis]

On 2021-06-27 14:23, Brian Inglis wrote:
> On 2021-06-26 20:38, Dietmar May via Cygwin wrote:
>> On 6/26/2021 3:17 PM, Brian Inglis wrote:
>>> On 2021-06-25 14:46, Dietmar May via Cygwin wrote:
>>>> The build completes successfully by replacing the "cmd /c | sed" 
>>>> construct with simply:
>>>> func_convert_core_msys_to_w32_result=$1
>>>> so no path translation takes place.
>>>> The function then becomes:
>>>> func_convert_core_msys_to_w32 ()
>>>> {
>>>>    $debug_cmd
>>>> func_convert_core_msys_to_w32_result=$1
>>>> }
> 
>>>>> SUMMARY
>>>>> func_convert_core_msys_to_w32 in
>>>>> /usr/share/libtool/build-aux/ltmain.sh
>>>>> has an extraneous '/' in the call to
>>>>> ( cmd //c echo "$1" )
>>>>> causing make to hang indefinitely
>>>>> when configured with
>>>>> --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
> 
>>> Which you don't need to change if you configure properly, as JonY 
>>> replied on the list to your earlier post:
> 
>>> On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
>>>> Don't set --build, you are building on Cygwin, not MSYS.
> 
>> Jonathan Yong is correct - removing --build allows make to complete 
>> without error using the unmodified ltmain.sh > There's still the issue 
>> of generating a call to cmd.exe with an
>> invalid switch (//c), which will cause it to hang indefinitely if
>> ever invoked.
>  > The risk of breaking anything by fixing this seems like nil.
> 
> The issue exists in the package libtool upstream:
> 
> https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n963
> 
> I submitted a bug report with link to this thread and patch to the 
> upstream package maintainers; I will post any responses received.

I can now see what may be a duplicate report under:

	https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949

responding that //c is deliberate so MSYS does not convert a posix path,
so 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.]

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Brian Inglis]

On 2021-06-26 20:38, Dietmar May via Cygwin wrote:
> On 6/26/2021 3:17 PM, Brian Inglis wrote:
>> On 2021-06-25 14:46, Dietmar May via Cygwin wrote:
>>> The build completes successfully by replacing the "cmd /c | sed" 
>>> construct with simply:
>>> func_convert_core_msys_to_w32_result=$1
>>> so no path translation takes place.
>>> The function then becomes:
>>> func_convert_core_msys_to_w32 ()
>>> {
>>>    $debug_cmd
>>> func_convert_core_msys_to_w32_result=$1
>>> }

>>>> SUMMARY
>>>> func_convert_core_msys_to_w32 in
>>>> /usr/share/libtool/build-aux/ltmain.sh
>>>> has an extraneous '/' in the call to
>>>> ( cmd //c echo "$1" )
>>>> causing make to hang indefinitely
>>>> when configured with
>>>> --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32

>> Which you don't need to change if you configure properly, as JonY 
>> replied on the list to your earlier post:

>> On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
>>> Don't set --build, you are building on Cygwin, not MSYS.

> Jonathan Yong is correct - removing --build allows make to complete 
> without error using the unmodified ltmain.sh > There's still the issue of generating a call to cmd.exe with an
> invalid switch (//c), which will cause it to hang indefinitely if
> ever invoked.
 > The risk of breaking anything by fixing this seems like nil.

The issue exists in the package libtool upstream:

https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n963

I submitted a bug report with link to this thread and patch to the 
upstream package maintainers; I will post any responses received.

-- 
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.]

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Dietmar May]

Jonathan Yong is correct - removing --build allows make to complete 
without error using the unmodified ltmain.sh

There's still the issue of generating a call to cmd.exe with an invalid 
switch (//c), which will cause it to hang indefinitely if ever invoked.

The risk of breaking anything by fixing this seems like nil.
------------------------------------------------------------------------
On 6/26/2021 3:17 PM, Brian Inglis wrote:
> On 2021-06-25 14:46, Dietmar May via Cygwin wrote:
>> The build completes successfully by replacing the "cmd /c | sed" 
>> construct with simply:
>>
>> func_convert_core_msys_to_w32_result=$1
>>
>> so no path translation takes place.
>>
>> The function then becomes:
>>
>> func_convert_core_msys_to_w32 ()
>> {
>>    $debug_cmd
>>
>> func_convert_core_msys_to_w32_result=$1
>>
>> }
>
>>> SUMMARY
>>>
>>> func_convert_core_msys_to_w32 in
>>>
>>> /usr/share/libtool/build-aux/ltmain.sh
>>>
>>> has an extraneous '/' in the call to
>>>
>>> ( cmd //c echo "$1" )
>>>
>>> causing make to hang indefinitely
>>>
>>> when configured with
>>>
>>> --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
>
> Which you don't need to change if you configure properly, as JonY 
> replied on the list to your earlier post:
>
> On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
>  >
>  > Don't set --build, you are building on Cygwin, not MSYS.
>

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Brian Inglis]

On 2021-06-25 14:46, Dietmar May via Cygwin wrote:
> The build completes successfully by replacing the "cmd /c | sed" 
> construct with simply:
> 
> func_convert_core_msys_to_w32_result=$1
> 
> so no path translation takes place.
> 
> The function then becomes:
> 
> func_convert_core_msys_to_w32 ()
> {
>    $debug_cmd
> 
> func_convert_core_msys_to_w32_result=$1
> 
> }

>> SUMMARY
>>
>> func_convert_core_msys_to_w32 in
>>
>> /usr/share/libtool/build-aux/ltmain.sh
>>
>> has an extraneous '/' in the call to
>>
>> ( cmd //c echo "$1" )
>>
>> causing make to hang indefinitely
>>
>> when configured with
>>
>> --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32

Which you don't need to change if you configure properly, as JonY 
replied on the list to your earlier post:

On 2021-06-25 09:27, Jonathan Yong via Cygwin wrote:
  >
  > Don't set --build, you are building on Cygwin, not MSYS.

-- 
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.]

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Dietmar May]

The build completes successfully by replacing the "cmd /c | sed" 
construct with simply:

func_convert_core_msys_to_w32_result=$1

so no path translation takes place.

The function then becomes:

func_convert_core_msys_to_w32 ()
{
   $debug_cmd

func_convert_core_msys_to_w32_result=$1

}


> SUMMARY
>
> func_convert_core_msys_to_w32 in
>
> /usr/share/libtool/build-aux/ltmain.sh
>
> has an extraneous '/' in the call to
>
> ( cmd //c echo "$1" )
>
> causing make to hang indefinitely
>
> when configured with
>
> --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
>
>
> The project builds successfully on msys2 & mingw-w64-x86_64-gcc 
> installed, as well as on git-for-windows-sdk (which uses msys2). msys2 
> has the same issue ('//c'), but the compiler is in the path, so no 
> cross-compilation configuration is needed (and apparently this 
> function is not invoked).
>
>
> DETAILS
>
> func_convert_core_msys_to_w32() in the generated libtool script, when 
> configured using --build and --host for mingw, expands to:
>
> cmd //c echo ... | sed
>
> //c is not a valid option to cmd.exe, and causes cmd.exe to hang 
> indefinitely. This is reproducible from the command line:
>
> cmd //c echo .libs/ | /usr/bin/sed -e 's/[ ]*$//' -e 
> 's|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
>
> ps aux shows cmd.exe, with sed at pid cmd.exe + 1. kill is the only 
> way to terminate.
>
> By changing "cmd //c" to "cmd /c", the command completes successfully.
>
>
> /usr/share/libtool/build-aux/ltmain.sh is the template, which contains 
> the code:
>
> # func_convert_core_msys_to_w32 ARG
> # Convert file name or path ARG from MSYS format to w32 format. Return
> # result in func_convert_core_msys_to_w32_result.
> 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` |
>     $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
> }
> #end: func_convert_core_msys_to_w32
>
> I've been able to get past this problem by editing this file and 
> running configure again.
>
> Unfortunately, make aborts at a later point with a different (but 
> perhaps related?) error:
>
> func_to_tool_file src/.libs/libopenocd.libcmd
>
> func_convert_file_msys_to_w32 src/.libs/libopenocd.libcmd
> func_convert_core_msys_to_w32 src/.libs/libopenocd.libcmd
> func_convert_file_check src/.libs/libopenocd.libcmd 
> src\\.libs\\libopenocd.libcmd
> func_execute_cmds $AR $AR_FLAGS $oldlib$oldobjs~$RANLIB $tool_oldlib 
> exit $?
>  exit $?w_eval x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src\\.libs\\libopenocd.libcmd
> func_quote_for_expand x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src\\.libs\\libopenocd.libcmd
> func_notquiet x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src\\.libs\\libopenocd.libcmd
> func_echo x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src\\.libs\\libopenocd.libcmd
>
>
> libtool: link: x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src\\.libs\\libopenocd.libcmd
>
> : No such file or directory\.libs\libopenocd.libcmd
> make[2]: *** [Makefile:2811: src/libopenocd.la] Error 1
>
> The file *is* there:
>
> $ ls src/.libs
> libopenocd.lax  libopenocd.libcmd
>
> Running the command directly completes with no errors:
>
> $ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src\\.libs\\libopenocd.libcmd
> $
>
>
> One thing I don't understand is why libtool is converting paths to 
> windows format to run inside of a cygwin shell. The command completes 
> successfully *if no path conversion occurs* - so why bother?
>
> $ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
> @src/.libs/libopenocd.libcmd
>
> $
>
> Is this a holdover from 13 year old mingw behavior? or related somehow 
> to running autotools in a cmd.exe environment (like Microsoft's 
> original NT "posix" subsystem, a port of gnu commands to run 
> "natively" under cmd.exe)?
>
> Can libtool just ditch all of the back and forth path conversions, and 
> simplify all of this?
>
>
> REPRODUCING
>
> Install mingw64-x86_64-gcc-g++, autoconf, autoconf2.1, autoconf2.5, 
> automake and pkg-config in cygwin.
>
> I believe that will pull in all required dependencies.
>
>
> git clone https://git.code.sf.net/p/openocd/code
>
> cd openocd
>
> ./bootstrap
>
> ./configure --disable-werror --disable-doxygen-pdf --enable-ftdi 
> --enable-jlink --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
>
> make # or make -j8
>
>

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Jonathan Yong]

[-- Attachment #1.1.1: Type: text/plain, Size: 261 bytes --]

On 6/25/21 2:34 PM, Dietmar May via Cygwin wrote:
> 
> ./configure --disable-werror --disable-doxygen-pdf --enable-ftdi 
> --enable-jlink --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
> 

Don't set --build, you are building on Cygwin, not MSYS.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 5627 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Dietmar May]

SUMMARY

func_convert_core_msys_to_w32 in

/usr/share/libtool/build-aux/ltmain.sh

has an extraneous '/' in the call to

( cmd //c echo "$1" )

causing make to hang indefinitely

when configured with

--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32


The project builds successfully on msys2 & mingw-w64-x86_64-gcc 
installed, as well as on git-for-windows-sdk (which uses msys2). msys2 
has the same issue ('//c'), but the compiler is in the path, so no 
cross-compilation configuration is needed (and apparently this function 
is not invoked).


DETAILS

func_convert_core_msys_to_w32() in the generated libtool script, when 
configured using --build and --host for mingw, expands to:

cmd //c echo ... | sed

//c is not a valid option to cmd.exe, and causes cmd.exe to hang 
indefinitely. This is reproducible from the command line:

cmd //c echo .libs/ | /usr/bin/sed -e 's/[ ]*$//' -e 
's|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'

ps aux shows cmd.exe, with sed at pid cmd.exe + 1. kill is the only way 
to terminate.

By changing "cmd //c" to "cmd /c", the command completes successfully.


/usr/share/libtool/build-aux/ltmain.sh is the template, which contains 
the code:

# func_convert_core_msys_to_w32 ARG
# Convert file name or path ARG from MSYS format to w32 format. Return
# result in func_convert_core_msys_to_w32_result.
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` |
     $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
}
#end: func_convert_core_msys_to_w32

I've been able to get past this problem by editing this file and running 
configure again.

Unfortunately, make aborts at a later point with a different (but 
perhaps related?) error:

func_to_tool_file src/.libs/libopenocd.libcmd

func_convert_file_msys_to_w32 src/.libs/libopenocd.libcmd
func_convert_core_msys_to_w32 src/.libs/libopenocd.libcmd
func_convert_file_check src/.libs/libopenocd.libcmd 
src\\.libs\\libopenocd.libcmd
func_execute_cmds $AR $AR_FLAGS $oldlib$oldobjs~$RANLIB $tool_oldlib exit $?
  exit $?w_eval x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd
func_quote_for_expand x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd
func_notquiet x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd
func_echo x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd


libtool: link: x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd

: No such file or directory\.libs\libopenocd.libcmd
make[2]: *** [Makefile:2811: src/libopenocd.la] Error 1

The file *is* there:

$ ls src/.libs
libopenocd.lax  libopenocd.libcmd

Running the command directly completes with no errors:

$ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd
$


One thing I don't understand is why libtool is converting paths to 
windows format to run inside of a cygwin shell. The command completes 
successfully *if no path conversion occurs* - so why bother?

$ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src/.libs/libopenocd.libcmd

$

Is this a holdover from 13 year old mingw behavior? or related somehow 
to running autotools in a cmd.exe environment (like Microsoft's original 
NT "posix" subsystem, a port of gnu commands to run "natively" under 
cmd.exe)?

Can libtool just ditch all of the back and forth path conversions, and 
simplify all of this?


REPRODUCING

Install mingw64-x86_64-gcc-g++, autoconf, autoconf2.1, autoconf2.5, 
automake and pkg-config in cygwin.

I believe that will pull in all required dependencies.


git clone https://git.code.sf.net/p/openocd/code

cd openocd

./bootstrap

./configure --disable-werror --disable-doxygen-pdf --enable-ftdi 
--enable-jlink --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32

make # or make -j8