Page MenuHomeFreeBSD

Stop installing clang, clang++, and clang-cpp hardlinks in /usr/bin.
Needs RevisionPublic

Authored by kib on Jul 24 2019, 9:45 PM.

Details

Summary

They conflict with the same binaries installed by devel/llvm, and hide the version of clang that user wanted to install.

The change makes both gcc and clang, as well as g++ and clang++ handled same: they come from ports. Base system compiler is called cc/c++, whatever is it.

Test Plan

Exp run would be needed after the review.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 25503

Event Timeline

kib created this revision.Jul 24 2019, 9:45 PM
rgrimes accepted this revision.Aug 15 2019, 4:50 PM
This revision is now accepted and ready to land.Aug 15 2019, 4:50 PM

Which package provides clang? I don't have a /usr/local/bin/clang on my system.

kib added a comment.Aug 15 2019, 6:43 PM

Which package provides clang? I don't have a /usr/local/bin/clang on my system.

devel/llvm

cem accepted this revision.Aug 15 2019, 6:45 PM
cem added a subscriber: cem.

Which package provides clang? I don't have a /usr/local/bin/clang on my system.

llvm-devel drops a /usr/local/llvm-devel/bin/clang, although not a default prefix.

kib added a comment.Aug 15 2019, 7:05 PM
solo% ls -l /usr/local/bin/clang                                              ~
lrwxr-xr-x  1 root  wheel  7 Aug  5 22:10 /usr/local/bin/clang -> clang90
solo% pkg which /usr/local/bin/clang                                          ~
/usr/local/bin/clang was installed by package llvm-90
solo% pkg which /usr/local/bin/clang90                                        ~
/usr/local/bin/clang90 was installed by package llvm90-9.0.0.r1_1
seanc accepted this revision.Aug 15 2019, 7:31 PM
seanc added a subscriber: seanc.

No objection from me

dim added a comment.Aug 16 2019, 6:10 AM

I still don't see the problem, but if this is the way people want it, I'm fine with it.

imp requested changes to this revision.Aug 16 2019, 1:45 PM

I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).

And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.

This revision now requires changes to proceed.Aug 16 2019, 1:45 PM
kib added a comment.Aug 16 2019, 2:28 PM
In D21060#462930, @imp wrote:

I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).

See below.

And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.

I stated that exp run is required after the discussion is finished. I see no reason to ask portmgr to spend their time unless there is a clear route to commit the change.

WRT to optional symlinks, I am fine with it as far as defaults are to not have them. The reason for this change is to remove the surprise and the need to answer 'why' questions for people that start developing on FreeBSD. The same group of people are proficient in Linux and they do not have to manipulate $PATH or create symlinks in ~/bin because 'this is how FreeBSD happens to not-handle it' for all the time (it == conflict between base and ports binaries). If symlinks are on by default, this change does not worth the time.

imp added a comment.Aug 16 2019, 4:07 PM
In D21060#462958, @kib wrote:
In D21060#462930, @imp wrote:

I'd personally rather see us bring back something from the past . We had WITH_CLANG_AS_CC which controlled creating cc->clang links. What if we had WITH_CLANG_LINKS or similar that would create clang->cc links and have it default to off? This isn't blocking if there's no support for it, though. I didn't click request changes for this :).

See below.

And have you done an EXP run too see what the fallout is? My 'request changes' is a hard no until that's run and any issues resolved.

I stated that exp run is required after the discussion is finished. I see no reason to ask portmgr to spend their time unless there is a clear route to commit the change.
WRT to optional symlinks, I am fine with it as far as defaults are to not have them. The reason for this change is to remove the surprise and the need to answer 'why' questions for people that start developing on FreeBSD. The same group of people are proficient in Linux and they do not have to manipulate $PATH or create symlinks in ~/bin because 'this is how FreeBSD happens to not-handle it' for all the time (it == conflict between base and ports binaries). If symlinks are on by default, this change does not worth the time.

Yea, we'd default to NO. If we do it at all...

Personally, I'd like to see us add a way to compile in /usr/local/* into our compiler paths as that's been a more significant pain point for me than the which clang do I have...

jhb added a subscriber: jhb.Aug 16 2019, 6:17 PM

FWIW, gcc4.2.1 does get installed as /usr/bin/gcc on platforms that use it as /usr/bin/cc, and the base/gcc port that installs gcc6 as /usr/bin/cc also installs it as /usr/bin/gcc. I think gcc may be slightly different though in that autoconf scripts tend to look specifically for gcc sometimes instead of cc. I haven't run into similar configure scripts that look specifically for 'clang'. In my experience they look for 'cc' which happens to be clang.

kib added a comment.Aug 17 2019, 11:07 AM
In D21060#463035, @jhb wrote:

FWIW, gcc4.2.1 does get installed as /usr/bin/gcc on platforms that use it as /usr/bin/cc, and the base/gcc port that installs gcc6 as /usr/bin/cc also installs it as /usr/bin/gcc. I think gcc may be slightly different though in that autoconf scripts tend to look specifically for gcc sometimes instead of cc. I haven't run into similar configure scripts that look specifically for 'clang'. In my experience they look for 'cc' which happens to be clang.

configure generated by autoconf always looks for gcc first, AFAIR. One of my problematic use cases is 'CC=clang CXX=clang++ ../src/configure' of course.