[solved] Why no /usr/bin/clang link?

[pjp]

I have not found an explanation, only an aside mention that it doesn't exist.

Clang is not added to /usr/bin and instead lives in a separate path that is added to the PATH variable.

https://wiki.gentoo.org/wiki/Clang#sudo ... _not_found

So, why /usr/bin/gcc, but not /usr/bin/clang?

[Ionen]

Because gcc is otherwise not in PATH, while clang is -- making it unnecessary for the latter. Their management just haven't been designed the same way for handling multiple versions (slots) and such.

gcc may have more historical hardcoded paths hanging around too, while clang is unlikely to.

Trying to call a compiler using "secure" limited PATH seem kind of a odd thing to need too (emerge won't use that). Not that these can't be modified if need be.

Edit: also we've been trying to reduce the amount of modifications to the live system, e.g. tools like gcc-config that create a bunch of symlinks straight in /usr not tracked by the package manager, and with llvm's large amount of binaries and split packages it'd be messy to use common wrappers, or app-alternatives-like ebuilds ultimately would likely still want PATH for switching.

[pjp]

Thank you, I appreciate the details. I presumed there was a degree of "upstream" involved.

I guess I've done things to make it not in my PATH. I vaguely recall having avoided some /etc/profile change a long time ago that altered root's PATH. Maybe there were other changes I also avoided. I've never been a fan of random programs polluting global PATH.

I'm now noticing /etc/env.d and... that looks like a nightmare. Hard coding versions into a path variable seems like a bad alternative to a /usr/bin/clang link.

Anyway, thanks again for the info.

[Ionen]

I'm now noticing /etc/env.d and... that looks like a nightmare. Hard coding versions into a path variable seems like a bad alternative to a /usr/bin/clang link.

Yeah, that does have problems when it comes to updating current shells every time (aka won't get new llvm PATH until relogin, or source /etc/profile, and those that don't or can't use /etc/profile need to update manually every time). Albeit that's only on "major" version numbers and isn't /that/ frequent with llvm.

fwiw I used bit of a hybrid approach with eselect-wine, symlinks are a pain to manage there too -- lot of bin/ stuff to match (winecfg, msidb, notepad, etc...), variants, slots, and not all wine versions even install the same binaries (and it changes on USE too!) making it hard to tell what to even cleanup or make in a "generic" way without risking breaking unrelated things in /usr/bin. So it uses PATH too but the path never changes, and instead it uses that private directory for updates. Not that fully happy with this still.

[pjp]

My initial thought was to hijack the install (bashrc) and add my own symlink. For now, I only need the one for clang. But making sure it is handled properly for updates might be a bigger pain than it is worth. I've also thought about adding some sort of bashrc trigger to notify something else to manage the link, but... it'd be easier to write a short script and run it manually when needed. Or, as has been my pattern so far, after being annoyed for a bit, I forget about it until the next time I want to test something quickly. :)