From: Dietmar May <dietmar.may@outlook.com>
To: cygwin@cygwin.com
Subject: Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32
Date: Fri, 25 Jun 2021 16:46:31 -0400 [thread overview]
Message-ID: <SN6PR13MB42696B324CBEDD12E21F948AE5069@SN6PR13MB4269.namprd13.prod.outlook.com> (raw)
In-Reply-To: <355a97ed-2076-6756-8a5f-227e44537136@outlook.com>
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
>
>
next parent reply other threads:[~2021-06-25 20:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <355a97ed-2076-6756-8a5f-227e44537136@outlook.com>
2021-06-25 20:46 ` Dietmar May [this message]
2021-06-26 19:17 ` Brian Inglis
2021-06-27 2:38 ` Dietmar May
2021-06-27 20:23 ` Brian Inglis
2021-06-27 22:00 ` Brian Inglis
[not found] <1f91bcfb-374f-7985-5b4e-c6e323de3cd8@outlook.com>
2021-06-28 16:29 ` Dietmar May
2021-06-28 17:06 ` Jonathan Yong
2023-07-25 16:19 ` Evgeny Grin
2021-06-28 13:56 Dietmar May
2021-06-28 14:49 ` René Berber
-- strict thread matches above, loose matches on Subject: below --
2021-06-25 14:34 Dietmar May
2021-06-25 15:27 ` Jonathan Yong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SN6PR13MB42696B324CBEDD12E21F948AE5069@SN6PR13MB4269.namprd13.prod.outlook.com \
--to=dietmar.may@outlook.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).