bug-libtool
[Top][All Lists]
Advanced

[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

Attachment: OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]