[llvm-dev] (Thin)LTO llvm build

Carsten Mattner via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 27 11:27:05 PDT 2016

On Tue, Sep 27, 2016 at 6:33 PM, Teresa Johnson <tejohnson at google.com> wrote:
> I can't reproduce the failure. I am building with a clang built
>    Release from recent source as my stage-1 bootstrap compiler:
>    clang version 4.0.0 (trunk 282322) (llvm/trunk 282341)

The clang I use was built from the 3.9 release branch:
clang version 3.9.1 (branches/release_39 281767)

Is that too old for it to build itself with ThinLTO?

> I am configuring the stage-2 bootstrap compiler with the following
> command, which largely is copied from your earlier email with your
> cmake command (changes noted below):
>   lto=Thin
>   type=Release
>   cflgs=-w
>   INSTALL_PREFIX=$HOME/llvm/${build_dir_name}/clang-install
>   BUILD_COMPILER=$HOME/llvm/llvm_10_release_build
>   SRC=$HOME/llvm/llvm_head
>   BINUTILS=$HOME/binutils/binutils
>   cmake \
>     -G Ninja \
>     -DCMAKE_BUILD_TYPE=${type} \
>     -DCMAKE_C_FLAGS=${cflgs} \
>     -DCMAKE_CXX_FLAGS=${cflgs} \
>     -DCMAKE_EXE_LINKER_FLAGS=${linkflgs} \
>     $SRC

Is BUILD_COMPILER/bin the result of a previous non-LTO build of trunk?

If any of you have suggestions what to omit from the above flags, I'm
open to suggestions. This is the culmination of trying to replicate
the previous autoconf flags. It's not an exact mapping, but almost.

> The changes from your config:
> 1) Used llvm-ar and llvm-nm from the build compiler. I noticed that
> you are specifying those as coming from the same directory used for
> CMAKE_INSTALL_PREFIX, which seems wrong - that is where the compiler
> built here will be installed.

That's because I'm reusing the previous built 3.9_release (without
LTO) and I move it away after the build before running ninja install
to the same location after extending PATH with the locally moved tree
of the previously installed PREFIX for llvm.

Is that a problem?

> 2) Used my own binutils checkout as I don't have plugin-api.h
> installed in /usr/include

Curious, is your host binutils too old for that to exist in

> 3) Set BUILD_SHARED_LIBS=ON (which I don't see in your earlier
> config, did you add that later?)

What I emailed earlier was the full set of flags passed to cmake, and
I had just added SHARED_LIBS=OFF as suggested for the next rebuild.

Should I use ON or OFF?

> 4) Set LLVM_PARALLEL_LINK_JOBS=1 (probably not needed)

I'll try this next time, just to see how much of a difference it makes
when I run with with -j4.

> 5) Build with -w, to avoid occasional issues with warnings only
> emitted by clang (probably not needed)
> 6) Specified CMAKE_C_COMPILER and CMAKE_CXX_COMPILER explicitly (you
> might have had the right versions in your path?)

I've exported CXX and CC to clang++ and clang, which happen to be the
locally build 3.9 release branch versions (non-LTO variant).

> I did an nm on the .so libraries to see where __morestack was
> referenced and its linkage. No surprise, it is coming from
> libLLVMRuntimeDyld.so, and I do see it as weak as expected:
> $ nm lib/libLLVMRuntimeDyld.so | grep morestack
>                  w __morestack
> Can you do the above nm on your lib/libLLVMRuntimeDyld.so and send
> me the output?

In the unfinished build dir I only have lib/libLLVMRuntimedyld.a.

More information about the llvm-dev mailing list