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