GNU bug report logs -
#49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32
Previous Next
Full log
Message #35 received at 49246 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
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.