Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin
Sorry for necroreply.
When *cross* compiling from Cygwin to MinGW (read: native Windows) the
different "--build" and "--host" must be used, like
--build=x86_64-pc-cygwin --host=x86_64-w64-mingw32
or
--build=x86_64-pc-cygwin --host=x86_64-pc-mingw64
as you are building is on Cygwin, not on MinGW.
--
Evgeny
On 25.06.2021 18:07, Dietmar May wrote:
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 clonehttps://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
OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin
On Fri, 25 Jun 2021, Dietmar May wrote: 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)? Libtool was last released in 2014. Nothing has changed since then. :-) Can libtool just ditch all of the back and forth path conversions, and simplify all of this? I am not sure what the current situation is now but MinGW compilers/tools used to accept Windows paths only because they were native Windows programs without any "POSIXization". Cygwin is a Unix emulation environment so it uses Unix-style paths. In the past, MinGW users often used MSYS. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin
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.
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 clonehttps://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
