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-mingw32The 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).
DETAILSfunc_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_w32I'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.libcmdfunc_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?
REPRODUCINGInstall 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
