[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in fu
From: |
Ileana Dumitrescu |
Subject: |
bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32) |
Date: |
Fri, 16 Aug 2024 17:37:46 +0300 |
User-agent: |
Mozilla Thunderbird |
On 15/08/2024 22: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).
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
After re-reading the bug report, I wonder if Brian's configuration is
setup incorrectly to cause this failure? Whether you are building on
MSYS for a MSYS host or building on MSYS for a Cygwin host, the same
format has been used: 'cmd //c ...'. The build environment should be
handling the command parsing at this point, correct? If MSYS is
executing the command, Brian would not have had hanging builds though. I
am not sure whether a new check should be added to libtool to handle the
type of configuration Brian seems to have or if something in Brian's
build is not configured properly.
I think I will revert the patch in development, but I will wait for
some feedback from those who can test this.
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
- bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32, Ileana Dumitrescu, 2024/08/14
- Message not available
- Message not available
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian Inglis, 2024/08/14
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Ileana Dumitrescu, 2024/08/14
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian . Inglis, 2024/08/14
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Ileana Dumitrescu, 2024/08/15
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Nick Bowler, 2024/08/15
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32),
Ileana Dumitrescu <=
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian . Inglis, 2024/08/17
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Nick Bowler, 2024/08/17
- bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32), Brian . Inglis, 2024/08/17