[llvm-dev] (Thin)LTO llvm build

[Carsten Mattner via llvm-dev]

On Tue, Dec 20, 2016 at 5:52 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

> What is your exact cmake invocation?

Same as in October, and this one for the next try, where I have
explicitly overriding all compiler and linker flags, which used to say
just -fuse-ld=gold before to make it work in October and from what I
remember extended it since the pre-set CFLAGS were still respected
back then.

Haven't tries this one yet, but it's what I intend to test next.

cmake \
    -G Ninja \
    -DCMAKE_BUILD_TYPE=Release \
    -DLLVM_BINUTILS_INCDIR=/usr/include \
    -DCMAKE_INSTALL_PREFIX=$PREFIX \
    -DLLVM_TARGETS_TO_BUILD="X86" \
    -DLLVM_ENABLE_BACKTRACES=OFF \
    -DLLVM_BUILD_EXAMPLES=OFF \
    -DLLVM_INCLUDE_EXAMPLES=OFF \
    -DLLVM_BUILD_TESTS=OFF \
    -DLLVM_INCLUDE_TESTS=OFF \
    -DLLVM_BUILD_DOCS=OFF \
    -DLLVM_INCLUDE_DOCS=OFF \
    -DLLVM_ENABLE_DOXYGEN=OFF \
    -DLLVM_ENABLE_SPHINX=OFF \
    -DLLDB_DISABLE_PYTHON=ON \
    -DCLANG_PLUGIN_SUPPORT=OFF \
    -DBUILD_SHARED_LIBS=OFF \
    -DCMAKE_AR=`which llvm-ar` \
    -DCMAKE_RANLIB=`which llvm-ranlib` \
    -DCMAKE_C_FLAGS="$CPPFLAGS $CFLAGS" \
    -DCMAKE_CXX_FLAGS="$CPPFLAGS $CXXFLAGS" \
    -DCMAKE_EXE_LINKER_FLAGS=$LDFLAGS \
    -DCMAKE_MODULE_LINKER_FLAGS=$LDFLAGS \
    -DCMAKE_SHARED_LINKER_FLAGS=$LDFLAGS \
    -DLLVM_ENABLE_LTO=Thin \
    -DLLVM_PARALLEL_LINK_JOBS=1

I should probably note that I build clang with polly support,
plus also lldb and libcxx.

I wonder if I should also do this:
-DCMAKE_CXX_FLAGS="$CPPFLAGS $CXXFLAGS -stdlib=libc++

But if I do that, I might also need to know how I can avoid libgcc and
use libunwind and rest of compiler-rt to make it free of any gcc
dependency, as a test and preparation of future defaults in llvm's
build scripts, as suggested by on this list a couple months ago.

> I don’t think cmake accept “LDFLAGS” directly, instead it is using
> “CMAKE_MODULE_LINKER_FLAGS”, “CMAKE_SHARED_LINKER_FLAGS”, and
> “CMAKE_EXE_LINKER_FLAGS”.

It does or it wouldn't otherwise respect what I set, and I've seen it
documented (would need to scour the web for reference) to do so by
design. However, I'm changing the configure invocation to explicitly
set all the CMAKE variables (I could find) explicitly, reusing what's
set in CFLAGS etc. before running cmake.

One interesting observation is that there's no CMake equivalent of
CPPFLAGS (needed for FORTIFY_SOURCE=2 which goes with
stack-protector). I've prepended $CFPPFLAGS to CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS which should hopefully work without causing any
errors. Technically FORTIFY_SOURCE is only for $CPP and neither $CC or
$CXX.