How clang from packages is build?

I was recently wondering how clang is build for packages? Is it regular Release (-O2), or is it some faster build like PGO/LTO etc?



I was wondering the same thing recently and Hans pointed me to llvm/utils/release.

It turns out we’re not using LTO :frowning:
(Neither PGO…)

In the Debian/Ubuntu packages (and this is general to packaging), we are:
* relying on the build system of the application itself
* adding some flags like "-g -O2" and the fortify options

For the linker, for the LLVM toolchain, it depends if the version of binutils in the distro has it or not (at least 2.23.1-1~exp3).
Here, for the Debian & Ubuntu packages, I am using binutils gold but not sure the LTO option is set to the llvm build system?!

However, happy to try that (I think this should be part of the build system, at least for LTO).


I think that's what the -LLVM_ENABLE_LTO={Full,Thin} option is for,
but it's not enabled by default.


So, what about changing this?

I don't know how practical it would be at the moment. Would most build
environments support it? It seems to assume Clang is being built by
Clang, and that the gold plugin (which I think requires the binutils
headers to build) is around.

+Ivan who knows everything about building things with LTO.

Aren’t you doing a 2-stage build? In which case the stage-2 always has clang available.
It requires Gold on linux probably, but on OSX the system linker supports LTO.

At minima the OSX build could have it enabled without risk of failure.

Hi Mehdi,

yes, on Linux we do 2-stage build exactly for this reason.
For the reference, the code is and we don’t make use of LLVM_ENABLE_LTO at the moment (no good reason I can think of)


In Chromium we only build the gold plugin with LTO though, not Clang
itself. IIRC (but my memory is hazy), we ran into problems when we
tried that?

I don’t recall any specific problems, but yeah, could be that there’re some.

I just tried and, with gcc 6.1 and GNU gold (GNU Binutils for Debian 2.26.1) 1.11

I am getting:
lto1: internal compiler error: in lhd_decl_printable_name, at langhooks.c:222
0x7fb47a lhd_decl_printable_name(tree_node*, int)
0x69a45e gen_namespace_die


The idea is to enable LTO on the stage-2 only, here you have a crash in GCC LTO during the stage-1 right?