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

On 09/07/12 17:09, Dimitry Andric wrote:
> 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? :)

I would appreciate such an approach, since it would be consistent with
with GCC, as you stated.

> 
> 
>> 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.

Understood.

> 
> 
>> 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.

The LibreOffice package doesn't compile with the system's CLANG, so it
is installed whenever LibreOffice is installed.

We have on all workstations running FreeBSD LibreOffice installed and so
devel/llvm and lang/clang get installed, as far as I know.

> 
> 
> ...
>> 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.)

Changed back, so hopefully no danger to pollute the list with more
questions about failures ;-)

Since I'm using on most boxes 10.0, where can I read more about the new
toolchain approach?

And by the way - is there a way to have also LLVM installed with the
base system by a knob like "WITH_LLVM"? This would avoid the same
confusion as mentioned above with CLANG when it comes to LLVM
dependencies (I play around with some OpenCL libs (pocl), which seems to
need LLVM port installed).

Thanks for your response,

regards

Oliver