LLVM/Clang Can Build LibreOffice

[DaemonFC]

I wouldn't trust anything that is under apple's hands and supervision (and generally most things that use a bsd license reek badly to me, but that's just a personal preference). Could be great software for all I care, but evil people have already achieved greatness in the past, that didn't cancel out their evilness though.

Still, ideally you should code against a standard, not against a compiler, just as you should design web pages against a standard and not against a browser.

I don't trust anything that the BSDaleks promote. That's before we even get to Apple.

[DeepDayze]

I wonder why people support Clang/llvm while there's Ekopath. It's probably more GCC compatible and beats cland/llvm in terms of performance badly. It also produces binaries that work. Btw. what do you mean by "wonder"?

Ekopath? I forgot about that one...maybe someone should try building LO with Ekopath vs GCC/Clang and benchmark the results.

As for "wonder compiler" I meant it with a little bit tongue in cheek.

[XorEaxEax]

I am sure someday Clang/LLVM will end up becoming the default compiler for the Linux kernel rather than GCC, once it matures.

I doubt that, not only are kernel devs very used to GCC but also they have a great deal of input on what GCC offers like compiler extensions which the kernel devs rely heavily on. Many of the GCC developers work for companies which are also employing kernel developers so there's a strong connection there aswell. Either way Clang/LLVM has a long way to go in terms of compability before that's even something to consider.

I think it's far more likely that LibreOffice invokes undefined or implementation-defined behaviour during startup, which is compiled in different ways by gcc and clang.

Sounds like 'magic' Anyway, this is not the first time I've come across code which compiles fine under Clang/LLVM and yet fails to run. I've also come across code which compile fine and actually run, but has broken output (Blender, x264), granted that was quite a while ago. Bugs will be squashed and it will become more mature/compatible with GCC as time goes on.

I wonder why people support Clang/llvm while there's Ekopath. It's probably more GCC compatible and beats cland/llvm in terms of performance badly. It also produces binaries that work. Btw. what do you mean by "wonder"?

First of all, ekopath only targets x64 (I think it works with 32-bit but it's unsupported) and no other cpu architectures, also atleast from my own tests it has a higher failure-rate when it comes to compiling than Clang/LLVM has (which is already quite high), however I've been using ekopath nightlies which are likely far from production quality so that may be part of the reason.

[DeepDayze]

I doubt that, not only are kernel devs very used to GCC but also they have a great deal of input on what GCC offers like compiler extensions which the kernel devs rely heavily on. Many of the GCC developers work for companies which are also employing kernel developers so there's a strong connection there aswell. Either way Clang/LLVM has a long way to go in terms of compability before that's even something to consider.


Sounds like 'magic' Anyway, this is not the first time I've come across code which compiles fine under Clang/LLVM and yet fails to run. I've also come across code which compile fine and actually run, but has broken output (Blender, x264), granted that was quite a while ago. Bugs will be squashed and it will become more mature/compatible with GCC as time goes on.


First of all, ekopath only targets x64 (I think it works with 32-bit but it's unsupported) and no other cpu architectures, also atleast from my own tests it has a higher failure-rate when it comes to compiling than Clang/LLVM has (which is already quite high), however I've been using ekopath nightlies which are likely far from production quality so that may be part of the reason.

While both Ekopath and Clang/LLVM are new compiler technologies, they are still under heavy development and will get better with each iteration so will be giving GCC a run for its money.

While GCC is favored by the kernel devs, competing compilers are using kernel compilation as a sort of Holy Grail. If a compiler can build structurally valid kernel binaries that run correctly without oopsing that is a good sign of a compiler's strength.

[XorEaxEax]

While both Ekopath and Clang/LLVM are new compiler technologies, they are still under heavy development and will get better with each iteration so will be giving GCC a run for its money.

Well, 'new' is relative. AFAIK Ekopath builds on a previous compiler and LLVM has been around since 2000 (although Apple started hiring people to work on it in 2005). Now what some people who advocate LLVM/Clang seem to forget is that GCC isn't standing still, in fact it's also improving at a brisk pace. Some of it's shortcomings have been improved such as faster compiling (meanwhile LLVM has gotten slower in compiling as it's become more feature complete), the plugin support, and there's been work on improving the diagnostics (although it has a long way to go before it catches up with LLVM in that regard). Also there's alot of work in code optimization where it's already way ahead of LLVM.

So we have two compilers, both going full steam ahead, both open source/free to use and atleast at the moment with diffeerent strenghts which means they can compliment eachother to the end-users benefit. Makes me a happy programmer!

While GCC is favored by the kernel devs, competing compilers are using kernel compilation as a sort of Holy Grail. If a compiler can build structurally valid kernel binaries that run correctly without oopsing that is a good sign of a compiler's strength.

Yes the Linux kernel is notoriously difficult to compile with anything other than GCC, some of which is due to the use of GCC specific extensions. On the other hand the kernel developers are mainly responsible for the existance of those compiler extensions since they've requested them so it goes without saying that they will use them. Apart from extensions I'd say the Linux kernel gives C and it's macro system a good workout aswell which is also likely to trigger existing bugs in a compiler.