Re: FreeBSD 10.0-CURRENT: CLANG and port/clang weirdness!

On 2012-09-07 11:41, O. Hartmann wrote:
> Building ports not explicitely enabling USE_GCC=4.6+ are considered
> using the system's LLVM/CLANG, which is clang 3.2 in our installation
> (FreeBSD 10.0-CURRENT #0 r240164), but since some ports require the
> special ports devel/llvm and lang/clang, LLVM 3.1 and clang 3.1 get
> installed and 3.1 is used instead the system's 3.2 whenever "clang",
> "clang++" is invoked.

Maybe a solution would be to use the same approach as with the gcc
ports, namely installing the clang 3.1 executables into /usr/local/bin
as clang-3.1, clang++-3.1 and clang-cpp-3.1.  Then you could simply set

CC=clang-3.1
CXX=clang++-3.1
CPP=clang-cpp-3.1

for the targets that require it.  Brooks? :)


> Following the WIKI at http://wiki.freebsd.org/BuildingFreeBSDWithClang
> introduces the usage of
>
> CC=clang instead of CC=/usr/bin/clang
> CXX=clang++ instead of CXX=/usr/bin/clang++
> CPP=clang-ccp instead of CPP=/usr/bin/clang-ccp
>
> Is this intended?

Yes.  During buildworld, in the cross-tools stage, a new compiler is
built, and it is placed under ${WORLDTMP}, usually /usr/obj/usr/src/tmp.
Afterwards, in the rest of the stages, the PATH is changed so
executables from ${WORLDTMP} are preferred above those in the system
directories.

Therefore, if you set CC/CXX/CPP with an explicit path, this logic will
not work, and your buildworld may have all kinds of trouble.  I think
there are several patches floating around to fix this, in various
different ways.


> Since I can not simply change the search patch - I need to have
> /usr/local/bin before /usr/bin, is there a way to avoid this confusion?

Yes, don't install the clang port, or do install it, but manually move
the conflicting executables away, or delete them.  This can't be fixed
without fixing the clang ports to accept an option to change the
compiler names into something non-conflicting.


...
> My /etc/make.conf portion looks this:
>
>
>
> ##
> ##      CLANG
> ##
> .if !defined(NO_CLANG)
> .if !defined(CC) || ${CC} == "cc"
> CC=                             /usr/bin/clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=                            /usr/bin/clang++
> .endif
> .if !defined(CPP) || ${CPP} == "cpp"
> CPP=                            /usr/bin/clang-cpp
> .endif

As said, putting an absolute path in these settings will defeat the
logic in buildworld.  Please don't do it, until there is a system in
place to make this possible.  (This is actually one of the stated goals
for 10.0, to be able to specify even external toolchains for building
world.)