Hot answers tagged llvm
Summary: The primary reason for switching from GCC to Clang is the incompatibility of GCC's GPL v3 license with the goals of the FreeBSD project. There are also political issues to do with corporate investment, as well as user base requirements. Finally, there are expected technical advantages to do with standards compliance and ease of debugging. Real world ...
One thing worth considering is that FreeBSD is currently using GCC 4.2.1 as noted in ire_and_curses answer thus the performance comparisons aren't of 4.5 or even 4.6 aren't truly relevant to the project. Therefore, the questions you should be asking are: What are the performance gains of the new Clang vs the older GCC that the project uses? How do the same ...
Even though GCC is GPLv3, the resulting binaries produced by GCC never had any license constraint. In clear you can use GCC to build software that falls under the license you want. Even the C library that comes with GCC and that is included in the binary is license-free. http://www.gnu.org/licenses/gcc-exception-faq.html Section 2 of the GNU GPLv3: You ...
I'm no expert, but my understanding is Clang/LLVM uses fewer resources than GCC and is quicker. http://clang.llvm.org/features.html#performance If you're running an environment where you need to build a lot of stuff, a lot of times, that performance may turn into real savings in energy costs and time. If it's real.
As a late response to this question, what @jmtd said is exactly what happens periodically in the Debian archive. Packages are recompiled with newer toolchains (compilers, linkers, etc.) and, when recompilation fails, bugs against the packages that failed to be compiled are filed with the indication of FTBFS ("failed to build from source"). Such bugs are ...
Not yet. According to this currently open bug report it seems even the kernel itself fails to compile.
The -j make flag denotes how many threads you want to allot for compiling. n is, in this case, a place-holder for the number of processes. The classic rule of thumb is that it's safe to make n = the number of cores your CPU has. So if you are on a dual core machine, you might use -j2, while on an 8-core machine -j8 In practise, I have found that to be a ...
Try setting the variables to the output of llvm-config using command substitutions, rather than the raw commands themselves: set -x CGO_CPPFLAGS (llvm-config --cppflags | tr -s ' ' \n) set -x CGO_LDFLAGS (llvm-config --ldflags --libs --system-libs all | tr -s ' ' \n) set -x CGO_CXXFLAGS '-std=c++11' The pipe through tr is to avoid getting bitten by a ...
I was able to build clang by following a modified version of steps you took. # Preliminary: # Get source # Extract source # Set environmental variables cd /home/avilella/src/llvm/latest # Clang is expected to be at `tools/clang`. mv tools/cfe-3.3.src tools/clang # You should clean before configuring, not after. make clean # The missing config.h file is ...
Whether it's safe to use n = number of cores also depends on whether you have enough memory for all the parallel compile/link jobs. It could also cause issues for disk I/O. If this is a make job you only expect to need to run once it's probably better to choose a lower n and just let it take its time.
Generally it's not a good idea to simply unpack an RPM and try to use it's content because: you have to resolve the dependencies you lose the so called RPM scripts, which might be vital for proper functioning you lose the original directory structure, which might be vital for proper functioning Number 2 and 3, are in fact rarely a problem (only happens ...
If you want Python 2.7 on a CentOS6 system, install the Python 2.7 Software Collection package. It will not replace /usr/bin/python, but if you load the python27 scl, configure will detect it. Note: you should just use the EPEL package for llvm if that's all you want.
The -j flag tells make(1) how many processes to run in parallel. Best value depends on the tasks run, dependencies, ... a rule of thumb is the number of processors. If you give just -j (no n), make starts as many processes in parallel as possible.
You're right - simply swapping toolchains will not magically make it work. As an experienced musl user I can say this will not work "out of the box". Many, many programs still require special cases glibc only provides which are even not in musl, and especially many GNU project programs will not even compile without glibc presence. The big work of fixing ...
Since Apple has bundled it's own version of gcc/llvm, you need to enable homebrew/versions repo before you can install different version of GCC. brew tap homebrew/versions brew install gcc48 Replace gcc48 with the version of gcc you want. See also https://github.com/mxcl/homebrew/wiki/Custom-GCC-and-cross-compilers
I think the problem is that you don't want the first two lines you put in /etc/apt/sources.list, namely deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty main deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty main I suspect these correspond to 3.5 (trunk). You can verify this by running apt-cache policy pkg1 ... pkgn where the pkgs run ...
Currently the LLVM apt repository states that it includes LLVM, Clang, compiler-rt, polly and LLDB. lld isn't included. Even the latest snapshot packages in Debian (which feed in to Ubuntu and are maintained by the same team as the LLVM packages) don't include lld. For now you'll need to build lld from source!
By the sounds of it, lld has not matched the maturity of Clang/LLVM yet, so it isn't included in the main packages. There is some confusion around the linkers in LLVM (I was quite confused myself). The rest of this answer (while not directly answering the original question) helps clear up the confusion to define what it is we are talking about! There are ...
Whilst the end-user binaries are not built with clang/llvm, most of the Debian archive has been built (and rebuilt) with clang/llvm (and binutils-gold and other bits and pieces) by people who want to expose portability bugs in the software suite (and the compilers themselves).
If you want a later version of clang installed on a regular basis you might want to add one of the PPAs on LaunchPad e.g. this one or this one. Once you have the PPA added to your /etc/apt resources, the package can update the package with the normal system update/upgrade just like gcc-snapshot would do. These PPAs are normally the latest, which means not ...
Only top voted, non community-wiki answers of a minimum length are eligible