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

Previous Next

Full log

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

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

On 2024-08-15 13:49, Nick Bowler wrote:
> 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).

VMS is yet another different kettle of fish with its own .com scripts!

> 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.

The same libtool can be run from a Cygwin, Msys2/Mingw64, or Msys/Mingw/32 
shell: as far as I know such recent shells are derived from Cygwin or upstream 
dash/mksh/tcsh sources, and I do not remember any such Windows switch or drive 
mangling, unless by ancient legacy original Mingw/32/Msys shells, which are 
unlikely to still be in use nowadays, as development and support likely long 
moved to their successors.

The config or runtime should be checking if any of these assumptions still hold 
in the shell interfaces, and also maybe use the supported shells rather than 
cmd, or is it just that the build environment is supported more by Windows than 
Unix devs?

I am still often surprised by how much legacy junk is in packages, based on 
assumptions about how Cygwin (Msys2, Mingw64, etc.) was many versions and 
decades ago, when it was less POSIX (and Linux, BSD, and Solaris) compliant and 
more Win32 compliant than now.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                -- Antoine de Saint-Exupéry

Previous Next

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