
Clang Is Now Used to Build Chrome for Windows - janvdberg
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html
======
equalunique
Have seen a couple interesting articles[0][1] highlighting the weirdness of
building Chromium on Windows, so hopefully this LLVM improvement will be a
step towards a smoother process.

[0] [https://randomascii.wordpress.com/2018/02/25/compiler-bug-
li...](https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-
windows-kernel-bug/)

[1] [https://randomascii.wordpress.com/2017/07/09/24-core-cpu-
and...](https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-
move-my-mouse/)

~~~
brucedawson
Hey, those are mine! Those two issues (and this one:
[https://randomascii.wordpress.com/2018/02/11/zombie-
processe...](https://randomascii.wordpress.com/2018/02/11/zombie-processes-
are-eating-your-memory/)) are equally problematic with clang. Two of them were
problems with Windows, and one was a flaw in a Microsoft system management
component.

Luckily they are all mitigated, fixed, or being fixed, so my Chrome builds run
much more smoothly now.

~~~
equalunique
Thank you for chiming in! Your articles are wonderful!

------
evmar
We first started fiddling with Clang for Chrome in late 2010:
[http://neugierig.org/software/chromium/notes/2011/01/clang.h...](http://neugierig.org/software/chromium/notes/2011/01/clang.html)

The original work was just finding bugs in the codebase and compiler. It's
gone so far!

------
tavert
> if your project is Windows-only, you can get a second compiler’s opinion on
> your code, and Clang’s warnings might find bugs

GCC (mingw.org and mingw-w64 triples) has existed and been able to do this,
including and especially cross-compiling, for a long time. No need to manually
download a Windows SDK either.

edited to add: to be fair, it's not ABI compatible with MSVC. But it deserves
a mention and it's an easier option than MSVC-style build systems for many
open source projects.

~~~
martell
mingw-w64 llvm maintainer/developer here.

Over the past 2-3 years, with great help from a few other LLVM devs I have
slowly pushed for native clang support for mingw-w64. With the current in tree
HEAD you can now build and bootstrap mingw-w64 with a llvm-only toolchain (no
binutils or gcc, thus no disregard of the PECOFF SPEC)

The stack is as follows. LLVM+CLANG+LLD+COMPILER-
RT+LIBCXX+LIBCXXABI+LIBUNWIND+MINGW-W64.

The libraries and executables built this way can be dropped into visual studio
quite easily, the two environments are now basically interchangeable. This
also means we can borrow the PDB debugging work by Zachary Turner and/or any
msvc features added to llvm for free that was done by the various googlers
working on chrome. See a talk from Reid on the most recent LLVM developer
meetup for more info on PDB and how it works. There has been no formal release
of this environment yet but you should see something in the coming
weeks/months. I keep build scripts here for those interested.

[https://github.com/martell/mingw-w64-clang](https://github.com/martell/mingw-w64-clang)

I'm due another cleanup of the repo now that wine 3.0 is out so I can actually
run x64 tests within a linux docker container. I'm going to be doing some
blogging to make this more visible with various partners that want to support
this.

The most interesting part of this for me was implementing a llvm-dlltool
alternative to binutils dlltool that actually works within the PECOFF spec so
msvc lib.exe and link.exe likes what it produces.

[https://reviews.llvm.org/rL308379](https://reviews.llvm.org/rL308379)

~~~
zturner
This sounds great, it's been a long time coming and I'm sure many people will
appreciate being able to debug their mingw generated executables in Visual
Studio.

I did all of the PDB stuff in LLVM, happy to help if you need it (ping me on
the mailing list or IRC)

~~~
martell
Updated the comment to reflect this. :) Thanks for all the good work. Will
ping you when I move onto that stage for support.

------
andreyv
> On the other hand, if all platforms use the same compiler, if it builds on
> your machine then it’s probably going to build on all platforms.

This also works the other way: buggy code that "works" in Clang may now go
unnoticed.

This means it will be harder to build Chromium using GCC or MSVC. I see that
Arch Linux already has to depend on Clang to build Chromium [1], which isn't
very reassuring.

[1]
[https://www.archlinux.org/packages/extra/x86_64/chromium/](https://www.archlinux.org/packages/extra/x86_64/chromium/)

------
Ono-Sendai
Great work by the Clang team, well done!

I'm a bit surprised to see that build times in Clang are worse, and that
resulting binary performance is comparable.

Maybe that will change when the Clang build starts to use LTCG, as the article
mentions.

~~~
DannyBee
Yeah, just things that aren't optimized yet. Windows headers, etc have very
different hot spots and need different paths to be fast than linux/mac ones.

For reference, in distributed builds, the build times are ridiculously faster
using clang. (it shaves many hours off the time).

~~~
tmzt
Is that due to the use of PCH in MSVC, so the hotspots only happen if the
headers change?

What does clang offer in this regard? Is incremental build sufficient?

~~~
DannyBee
No, clang offers precompiled headers as well.

It's literally things like "parsing large numbers of pragmas is slower in
clang because nobody has bothered to optimize it".

This is not uncommon for very different codebases.

Clang was, for a long time, many times slower at compiling the linux kernel,
for example, because the linux kernel headers have a _huge_ amount of inline
assembly and nobody ever bothered to optimize the parsing paths for inline
assembly. (now somewhat fixed).

This is just the very typical "hey, when you change the use cases
dramatically, you may need to retune/rethink how certain things are done"

I think people just may not realize how wildly different these types of
codebases are in what types of statements/things occur.

------
tsomctl
I didn't realize that clang is mostly a drop in replacement for cl, and
matches the C++ abi. That in of itself is awesome.

~~~
brucedawson
clang isn't. clang-cl is (after years of work by the clang-cl team at Google).
They had to do a lot of work, especially around PDB (symbol-file) generation.

~~~
zturner
More precisely:

clang-cl is a drop-in replacement for cl (even the command lines are the
same).

But clang-cl is just a driver for clang, and it's still possible to get the
ABI compatibility without clang-cl, but you have to know what you're doing and
get the flags right.

------
GeekyBear
For those interested in Clang history, here's Chris Lattner giving a tech talk
at Google introducing LLVM and Clang.

[https://www.youtube.com/watch?v=029YXzHtRy0](https://www.youtube.com/watch?v=029YXzHtRy0)

The Clang discussion begins at 18:53

------
quickben
Interesting. It seems Google is moving away from anything gpl/gnu lately
(fuchsia, etc...)

~~~
wongmjane
I think it is mainly due to their concerns over the Tivoization clause which
is added to GPLv3

~~~
DannyBee
Again, no, we didn't care.

First: We were already publishing all our GCC changes, as we did all our work
upstream (we worked on a staging branch in the gcc repo, and changes were
moved to trunk as fast as possible) Plenty of other companies used our branch
and we were happy with it.

We do all our work upstream for clang/llvm as well, and pull compiler releases
when upstream is green according to our internal testing. (Pretty much the
only cherry picks are a small number of reverts sometimes)

Second, literally nobody has ever come and expressed a concern about using GCC
to me.

I've had to explain the runtime and libstdc++ exceptions to people, but that
was the other way around -- They weren't worrying, and I needed to make sure
they worried and shipped source when they ship it as a .so.

------
xvilka
With Microsoft producing MSVC/C2 compiler with Clang frontend, I am surprised
they did not abandon the MSVC at all - they have a hard times even at
supporting C99, not to mention modern C++ technologies. And all those tools
and plugins built around Clang/LLVM. MSVC is a legacy of XX century and should
be abandoned for good.

~~~
pjmlp
They don't have any hard time supporting C99, from Microsoft point of view C
is done, time to move on to C++.

> We do not plan to support ISO C features that are not part of either C90 or
> ISO C++.

[https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-
an...](https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/)

All the updates regarding C99 and C11 in Visual C++ are related to ANSI/ISO
C++ requirements regarding C compatibility, as Herb states.

Regarding legacy, Visual C++ is one of the top C++ compilers doing incremental
compilation and linking, which still beats Rust compilation times on Windows.

~~~
wahern
Microsoft backpedaled not longer afterwards. See, e.g.,

[https://blogs.msdn.microsoft.com/vcblog/2013/06/28/c1114-stl...](https://blogs.msdn.microsoft.com/vcblog/2013/06/28/c1114-stl-
features-fixes-and-breaking-changes-in-vs-2013/)

and

[https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-libra...](https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-
support-in-visual-studio-2013/)

They even added C99 compound literals and designated initializers:

[https://msdn.microsoft.com/en-
us/library/hh409293(v=vs.120)....](https://msdn.microsoft.com/en-
us/library/hh409293\(v=vs.120\).aspx)

Compound literals could _never_ be added to C++ because the syntax and
semantics conflict with existing C++ constructs.

~~~
pjmlp
C99 and C11 library support is required by ANSI/ISO C++.

As for the minor language changes, there was a blog post that I cannot locate
now, stating it was to the extent required for porting well known projects to
Windows, the remaining features would depend on key customers feedback.

------
RandomCSGeek
Who are the "we" they refer to in this blog? Are they Google's devs who build
chrome, or are they clang's devs? If they are clang's dev, why are they
building chrome? I am completely confused on this one.

~~~
fooker
Google employs a large number of clang devs. I would not be surprised if it
was close to 50% of all clang (and LLVM) devs.

------
anfilt
And why not use mingw gcc? Do they find somthing wrong with it?

Edit Mingw-w64 its quite nice and includes gcc without all stuff cgwin does.

~~~
nice_byte
Why use it? llvm is the future anyway and lots of players have a stake in it
and contribute to it.

In fact, there are way too many c++ compilers if you ask me. I would gladly
accept a world where clang is the one and only.

~~~
tzahola
>I would gladly accept a world where clang is the one and only.

And luckily you don’t have any saying in such matters.

~~~
nice_byte
Sure. I just vote with my feet, like many others.

------
tomc1985
Last time I tried to build Chrome/Chromium I had to mess about with this build
system called Ninja. (Which worked well it was just awkward to set up on
Windows). Is that still in play?

~~~
xyzzyz
Ninja is used because it's simple, multiplatform and very fast. The mainstream
alternatives offer at most 2 out of 3.

~~~
cjhopman
"it's simple": yep, so much so that you inevitably need a meta-build system.
In the context of Chrome, the build system only offers 2 out of 3.

~~~
bigcheesegs
It's by design that you need a meta-build system. Ninja build files were not
designed to be written by hand, not even ninja itself has hand written ninja
files.

~~~
cjhopman
Yes, I understand that it's designed that way.

My point was that, in the context of Chrome using ninja, the claim that "Ninja
is used because it's simple, multiplatform and very fast. The mainstream
alternatives offer at most 2 out of 3." is a bit odd considering that the
decision doesn't seem to be ninja vs mainstream alternatives but rather
ninja+gn(or gyp or whatever else) vs alternatives.

------
bgussen
Did the LLVM folks fix the C++ structured exception handling incompatibility
between MSVC compiled DLLs/programs and LLVM compiled ones? This was a problem
for many years.

~~~
chandlerc1024
Yes.

(To the extent possible. There are some edge cases left, but they're _very_
rare. Essentially all the real-world code we've seen works now.)

~~~
AlexeyBrin
Tried to install Clang 5.0 Visual Studio integration, unfortunately it seems
that I need to install VS 2015 (v140) compiler since it doesn't work with VS
2017 (v141).

------
CyberDildonics
I've tried clang for windows twice. Each time the problem hasn't been the
compiler, which works well, it has been which library to use with it on
windows. Clang 5.0 worked well up until I needed the filesystem library, which
isn't there. Does anyone know if it still relies on the visual studio C++
library?

~~~
bigcheesegs
clang-cl is just a compiler. It relies on VS to provide the C and C++ standard
libraries. VS 2017 has the filesystem library and it should work with clang-cl
6.

~~~
brucedawson
To elaborate on that, if you want to build Chromium for Windows you currently
still need to install Visual Studio. We don't use its compiler anymore but we
use its linker and other tools, its header files, and its libraries. Many
Chromium developers also use it for editing code, and for debugging code.

Chrome is currently built using VS 2017 15.3 (that's update 3). Eventually we
will probably upgrade to VS 2017 15.7 in order to get more STL conformance,
linker improvements, etc.

~~~
notriddle
You need the MSVC build tools and the Windows SDK. You don't need the entire
Visual Studio.

~~~
voltagex_
Can you get the VS 2017 build tools separately any more?

~~~
oldmanhorton
Yep: [https://www.visualstudio.com/downloads/#build-tools-for-
visu...](https://www.visualstudio.com/downloads/#build-tools-for-visual-
studio-2017)

