On 09/07/12 19:07, Brooks Davis wrote: > On Fri, Sep 07, 2012 at 05:46:02PM +0200, O. Hartmann wrote: >> 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. > > I'd like to do this, but it doesn't look like it will be easy. There > appears to be no support in the llvm build system for it. :( > >>>> 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. > > FWIW, picking up clang etc from /usr/local should be mostly harmless > during the early build stage. You're actual world will be built with > the cross clang. ... means, the resulting WORLD and KERNEL is then build by the LLVM/CLANG that is residing in /usr/obj/...? But what is with PORTS I build later? They definitely pick up the "wrong" clang/clang++. I was suggested to deinstall (or not to install) the port's version of LLVM/CLANG, but this happens automatically for some ports - like LibreOffice. > >> Since I'm using on most boxes 10.0, where can I read more about the new >> toolchain approach? > > Discussions will take place on the toolchain_at_ list. I'll be posting > some writeups soon. > >> 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). > > You're probably looking for WITH_CLANG_EXTRAS. I already have that option enabled in my /etc/src.conf. But unfortunately, a tool called "llvm-config" and sibblings weren't installed, they get installed only with /usr/ports/devel/llvm[-devel]. I discovered this playing around with LLVM and there is a software package I play with (pocl, portable OpenCL library) which uses LLVM backend. At this point, my "point of view" might me wrong, but I look at CLANG as it is a part of the LLVM framework and so I inherently expected it to be existent (the LLVM) in FreeBSD. But I guess the policy in FBSD is to have only the clang and the necessary portions of LLVM in the tree. So I thought it would be nice to have the "magic knob" in case one will take the burden of compiling more and time consuming more LLVM/CLANG stuff if he chooses to do. > > -- Brooks > >> >> Thanks for your response, >> >> regards >> >> Oliver >> >> >
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC