bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32)
Nick Bowler <[email protected]> Thu, 15 Aug 2024 15:49:23 -0400
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <[email protected]> |
On 2024-08-15 11:22, Ileana Dumitrescu wrote: > I applied your patch through the existing testing framework and found no > issues, but I do not think I have the configuration setup to properly > test this bug. Looking through your explanation of the issue, I think > it is okay to apply the patch: > > https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=37b7146c13a62a46273fd1478e6ad8fe42f9b551 Unless I'm very confused by the duplicate/not duplicate discussion this cannot possibly be the right thing to do for MSYS. The MSYS shell automatically translates arguments to external commands that look like absolute POSIX filenames into absolute Windows filenames. This is problematic for VMS/DOS-like commands which usually have options starting with a slash, so MSYS allows you to call these by using two slashes (which it substitutes with a single slash before running the program). If you run the following command in the MSYS shell: cmd /c echo /home the command that actually gets run by Windows is: cmd C:/ echo C:/msys/home (or similar) which is bogus and just launches an interactive cmd prompt. It must be: cmd //c echo /home which prints C:/msys/home as expected. Cheers, Nick