libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin

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

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
$


I don't understand *why libtool is converting paths to windows format* 
in order 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 (along with make and git).

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