Plethora of tools installed in path can lead to corruption and unexpected behavior on Windows #11368
Open
3 of 16 tasks
Assignees
Labels
Comments
|
Hi @mitchcapper - Thank you for bringing this issue to our attention. We will look into this issue and will update you after investigating. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Officially a bug would be the fact ranlib.exe is added to the path and will operate on MSVC generated library files ("*.lib") but it will corrupt most libraries assembled by MSVC's lib.exe. This is probably best looked at not just excluding that from the path but offering potential path reduction as a recommended part of the workflow.
It is great the runner images provide so many dev tools but maybe there should be a way to choose if they are added to the path by default or not. IE a command to set which tools get added to the path.
I have a project compiling many common traditionally *nix tools for Windows in an automated fashion ( https://github.com/mitchcapper/WIN64LinuxBuild ). I use github actions and despite best efforts to avoid the built ins recently got bitten by mingw being added to the path (technically two mingw locations as the gh one is also thrown in). I thought I had fixed enough by removing the msys2 default install but not so much.
This can, of course, be fixed by the user if they just manually remove items they don't want from the path but that is a bit cumbersome and not very proactive as new things might get added.
If instead one could call an action like
set-pathand provide a list likevisual-studio, mingw, msys2etc to add to the path then people using github actions might get fewer bad surprises.While not super relevant here, in my case it was the presence of ranlib in the path that caused a long running and hard to track bug. Now this was a nice chain of failures to lead to it including the fact that ranlib can corrupt MSVC .lib files in a very subtle still partly usable fashion ( https://sourceware.org/bugzilla/show_bug.cgi?id=32550 ), or the fact that libtool will use ranlib if it is in the path even when it isn't needed on every library file it builds ( https://savannah.gnu.org/support/?111171 ).
It also wasn't reproducible locally as I didn't have so many tools in the default path.
Still, I thought I had cleaned the build env enough to avoid conflicts.
It doesn't seem like there is a shortage of bugs related the MinGW being in the path on here (including it being too old, or causing a mismatch with other installed version, etc). These things could be avoided if one could choose what goes in the path and what doesn't.
I have learned my lesson now, I strip path down to nothing re-add only the windows paths and the exact tool items I need, there may be a better approach though (and something that could proactively prevent conflicts for users rather than including everything in the build path).
Just a thought to give users an easy way to pair the path down to the tools they care about instead of:
As at least one major library building tool assumes ranlib needs to be called if it is in the path so avoiding that. I am not sure if there is even a use case in which ranlib is ever needed in the path for a windows library build.
Again, default behavior doesn't need to change (as clearly breaking things) but if best practice instructions were after checkout running something like
And along with that in the docs listed all the default options that were installed and could be part of the path. This also makes it easier as you add tools in the future to not have to worry about conflicts or versioning. Tools could even be opt in during a beta period (so default not in path, but if used with set-env would appear).
This would allow new users to hopefully configure it correctly by default. Existing projects wanting to eliminate a potential source of conflict could add it to their workflows but the default behavior would remain unchanged.
Platforms affected
Runner images affected
Image version and build link
n/a
Is it regression?
no
Expected behavior
no corruption of C++ library indexes
Actual behavior
ranlib leads to corruption of the lib index
Repro steps
run ranlib on the before lib in this zip to get the after lib note the differences in the index, and the incorrect handling of the backslash.
build_dbg.zip
Full details can be found on the binutils bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32550
The corruption that occurs is somewhat subtle too. Depending on the paths added by MSVC in the first place the library might be nearly the same, might have things re-allocated, or like here result in some really mangled items. Here, the error doesn't happen when the lib is built, or when ranlib is called right after, or in this case even after it is used within another library but not until a later compile stage for a tool in which you get a undefined reference but only for the mangled object in the lib.
The problem is further complicated that MSVC lib.exe actually shows a modified version of the data inside the library. A listing with it would show all the paths the same even though there are slashes going different directions in the binary data. It also shows different results from the binutils list after ranlib runs. Someone debugging this might just abandon trying to get that workflow to work or just switch away from MSVC completely.
The text was updated successfully, but these errors were encountered: