Skip to content

Conversation

NobodyXu
Copy link
Collaborator

@NobodyXu NobodyXu commented Oct 6, 2025

@NobodyXu NobodyXu requested review from ChrisDenton and madsmtm and removed request for madsmtm October 6, 2025 05:08
@NobodyXu NobodyXu enabled auto-merge (squash) October 6, 2025 11:53
@NobodyXu NobodyXu disabled auto-merge October 6, 2025 11:56
@NobodyXu NobodyXu requested a review from dot-asm October 6, 2025 11:59
Remove `.exe` suffix since `which` automatically applies it on windows
@NobodyXu NobodyXu requested a review from dot-asm October 6, 2025 12:11
@dot-asm
Copy link
Contributor

dot-asm commented Oct 6, 2025

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.

@dot-asm
Copy link
Contributor

dot-asm commented Oct 6, 2025

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.

@NobodyXu NobodyXu merged commit 61f9698 into main Oct 6, 2025
238 of 240 checks passed
@NobodyXu NobodyXu deleted the NobodyXu-patch-1 branch October 6, 2025 21:22
@NobodyXu
Copy link
Collaborator Author

NobodyXu commented Oct 6, 2025

Thank you dot-asm!

so to sum up, if we want to support gcc for search_programs we might want

  • no utf-8 support
  • passing target flags

@dot-asm
Copy link
Contributor

dot-asm commented Oct 7, 2025

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 about exclusively about -m64/-m32. Omitting them when probing shouldn't be a problem, because it's practically guaranteed that accompanying 'ar' can handle either. --target=* is significant in clang context, but even here omitting it shouldn't be a problem, because accompanying llvm tools can handle either target gracefully. The keywords in this paragraph is "should" as in "shouldn't be a problem."

To summarize it's not much of "might want," but rather be aware and ready to tell users what's wrong with their installations.

@NobodyXu
Copy link
Collaborator Author

NobodyXu commented Oct 7, 2025

Got it, thank you for the detailed explanation.

Basically it's something to be put into comment for debugging if gcc is used

@github-actions github-actions bot mentioned this pull request Oct 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support c/c++ library internal LTO

2 participants