GNU bug report logs - #49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32

Previous Next

Full log

Message #32 received at 49246 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: ileanadumitrescu95 <at> gmail.com
Cc: 49246 <at> debbugs.gnu.org, Brian.Inglis <at> SystematicSW.ab.ca
Subject: Re: bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw
 hangs in func_convert_core_msys_to_w32)
Date: Thu, 15 Aug 2024 15:49:23 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.