GNU bug report logs -
#49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 277 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.