-
Notifications
You must be signed in to change notification settings - Fork 543
Fix get_base_archiver_variant
for clang-cl: use --print-search-dirs
#1587
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Remove `.exe` suffix since `which` automatically applies it on windows
On a tangential, yet related note. Related to the remark about possibility of using search_programs even with gcc. The commentary reads "clang driver appears to be forcing UTF-8 output even on Windows." This doesn't seem to apply to gcc driver. I reckon it's not fatal, because gcc on Windows people are not that likely to end up with non-ASCII path in the --print-search-dirs output. And if they do a) there normally is a fallback for search_programs; b) in gcc context it would be most critical in cross-compilation case, while on Windows cross-compile toolchain is more likely to be self-contained, so that fallback is virtually guaranteed to work. |
Another related note. The --print-search-dirs output depends on platform flags, such as --target=* and -m32/-m64. So that formally speaking search_programs should be probed with the said flags. However, one can make a case that omitting them is not fatal, because a) llvm tools are all multi-platform, so that any found on the the search path would do the job; b) in gcc case one would only look up ar, and the associated ar should handle the target. |
Thank you dot-asm! so to sum up, if we want to support gcc for search_programs we might want
|
UTF-8 problem is specific to gcc on Windows. And it's not given that one can actually solve it, not in most general case. Because gcc driver gets an opportunity to replace non-ASCII character with '?', which would be irreversible. I personally wouldn't bother actually doing something about this. Being aware of the issue and explaining it to affected users should be sufficient. It should be noted that at least MSYS2 installer refuses to proceed with installation to a directory with non-ASCII characters. It's probably safe to assume that other installers do the same. Or at least if they don't, one can argue that they should. In other words if somebody manages to install gcc in a directory with non-ASCII characters, they should be advised to reconsider. As for target flags. In gcc context it's To summarize it's not much of "might want," but rather be aware and ready to tell users what's wrong with their installations. |
Got it, thank you for the detailed explanation. Basically it's something to be put into comment for debugging if gcc is used |
Fix #1565 (comment)