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
