[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sr #110901] libtool hangs indefinitely on windows when used in msys due
From: |
Mitch |
Subject: |
[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug |
Date: |
Mon, 2 Dec 2024 16:32:43 -0500 (EST) |
Follow-up Comment #5, sr #110901 (group libtool):
My original quick-fix suggestion was to simply unset MSYS_ARG_CONV_EXCL in
libtool so the hack inplace would work.
Later for my own GNU builds I started to just add a flag that controlled of
the cmd.exe call should be as it is "//c" or without the MSYS hack, and only
a single slash.
Honestly though these are both poor as this function really leads to horrible
performance in windows.
Instead I would recommend something like:
https://github.com/mitchcapper/libtool/compare/add_bypass_path_conversion_opt
Yes it adds a new ENV var so nothing benefits from the fix initially. In fact
due to the nature of the bug no project will likely implement the flag in
their build process (unless they used the forward slash notation with relative
which would ensure msys escaping would not happen.
Instead this would be a user level flag that they would set similar to how
they set MSYS2_ARG_CONV_EXCL to control escaping.
While it would potentially make more sense for it to be a libtool command line
arg the problem there is the user would likely need to edit the build
/configure scripts manually to do so which would be a big pain.
Now this straight up bypasses the conversion rather than using the singular
slash as I originally did with a flag. The reason being for properly
configured filenames no translation is needed and the performance hit with
even the correctly working cmd.exe call is pretty huge. Windows has a "high"
cost for process spawning and that one command that is called on every path
spawns many processes. Part of this is sh/bash.exe on windows spawns an
additional copy of itself every time it goes to launch a process. In short a
single file conversion call causes:
A 'forked' sh.exe to then run'env.exe bash /usr/bin/cmd /c echo .libs/'. That
spawns env.exe, which spawns bash.exe. Thankfully echo is a builtin of
cmd.exe so no spawn there. Then we use sed to trim the result so that is
another copy of sh.exe that then calls sed.exe.
All in all to convert ".libs/" to the proper path you are talking about 8
processes started and terminated in series.
So bypassing any spawns is a huge performance increase.
If we don't want to do this sort of bypass option we should still give users
some way to avoid the double slash hack without them resorting to editing
libtool or the build commands itself. Heck most users probably just give up
instead when it freezes not knowing the issue.
One change we could do would be to be smarter about if we need to use the hack
at all. Relative paths, for example, I don't think ever need to be converted.
One could replace any backslashes with forward slashes as just about anything
windows should understand forward slashed paths.
Another option would be to potentially detect if cmd.exe needs a single slash
or double slash to be past in the configure script or just at the very start
of a libtool spawn. That won't help performance but would prevent hangs.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?110901>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
- [sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug,
Mitch <=