[llvm-dev] (Thin)LTO llvm build

Tue Sep 27 14:17:49 PDT 2016

On Tue, Sep 27, 2016 at 2:00 PM, Carsten Mattner <carstenmattner at gmail.com>
wrote:

> On Tue, Sep 27, 2016 at 8:37 PM, Teresa Johnson <tejohnson at google.com>
> wrote:
>
> Just in case it's important, I'm using Arch Linux (and most Linux
> distros these days) CFLAGS/CPPFLAGS/LDFLAGS, which are as follows:
>
> $ grep FLAGS /etc/makepkg.conf
> CPPFLAGS="-D_FORTIFY_SOURCE=2"
> CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
> CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
> LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
>
> This is the same way Fedora or Arch linux would build clang, or any
> other usual package for that matter.
>

Ok, thanks will also try adding these.

>
> The only uncommon thing I set is the macro -D_GLIBCXX_USE_CXX11_ABI=0,
> which I use to avoid C++11 ABI chaos since g++5.x, although it's
> probably safe to drop by now, especially when CXX=clang++. That's
> g++-specific, so is irrelevant to the issue at hand.
>
> > I wonder if there is a bug that was fixed. I have bootstrapped with
> > ThinLTO with the 3.9 compiler, but not with LLDB and not with
> > SHARED_LIBS=ON. I can try with an older 3.9 version.
>
> As you seem to have faster hardware, I would appreciate a validation
> before I embark on another >=3h build endavour.
>

Sure, I will try this and let you know. Unfortunately, though, I have
another big work commitment
that is going to eat up most of my time through Thu, although I may be able
to find some time to
try it.

> > Not sure I followed that, but in essence you just want to make sure that
> > llvm-ranlib and llvm-ar match the build compiler.
>
> Sorry for the confusing description.
>
> I build llvm and install it locally in my home dir somewhere
> ($PREFIX). After building llvm, I move that installation out of the
> way before installing the new build in a now empty $PREFIX, but not
> before prepending the moved-to PREFIX in $PATH, in case I need the old
> toolchain during 'ninja install'.
>
> Make more sense?
>

I think so - what is confusing me is that your cmake command is specifying
the same $PREFIX
for both the install destination and the source of the llvm-ar/llvm-ranlib
that will be used in the new
build. Should the llvm-ar/llvm-ranlib in the cmake command use your
moved-to PREFIX instead?

> > I used ON to try to reproduce your issue, the OFF was a suggestion
> > to avoid it as a workaround. I'm surprised your build defaults this
> > to ON, according to http://llvm.org/docs/CMake.html it defaults to
> > OFF.
>
> Hmm, I will explicitly set it to OFF in the next build.
>
> Is it expected for the .so files listed below to be created with
> SHARED_LIB=OFF?
>

I do get a few .so with my default SHARED_LIB=OFF build, although I am not
building
some of those (e.g. the omp and polly libs). Maybe the error is actually
coming from one
of those, not libLLVMRUntimedyld.so. Although the only .so I see in your
link below is
lib/liblldb.so.3.9.1. Mine (lib/liblldb.so.4.0.0) doesn't reference
morestack.

Can you nm the .so files in your lib dir and see if any reference
__morestack?

Although it would be strange if they aren't referenced in the failing link.

Thanks,
Teresa

> > This is from your SHARED_LIBS=OFF build I assume? With the build
> > containing the DSO error I'm assuming BUILD_SHARED_LIBS=ON, which
> > would mean this should be a .so.
>
> One would expect so, but in fact it's with the flags I posted
> yesterday, so I'm equally confused as to why there's no .so, but the
> error
>
> These are the DSO file in lib/:
>
> $ ls lib/*.so
> lib/BugpointPasses.so
> lib/libclang.so
> lib/libgomp.so
> lib/libiomp5.so
> lib/liblldb.so
> lib/libLTO.so
> lib/libomp.so
> lib/LLVMgold.so
> lib/LLVMHello.so
> lib/LLVMPolly.so
>
> I'll assume, given the existence of the various .so files, that
> SHARED_LIBS=ON is the default and what's been configured.
>
> Unless cmake's configure step somehow is responsible for nuking
> libLLVMRUntimedyld.so, I don't know if it's supposed to exist yet in
> the build plan (failed) so far.
>
> > If this archive is from the build getting the DSO error then I'm
> > confused about which DSO is giving the error. In that case what does
> > the link line look like?
>
> For easier reading, I've newlined the parameters.
>
> [1/90] Linking CXX executable bin/lldb-3.9.1
> FAILED: bin/lldb-3.9.1
> : && $PREFIX/bin/clang++
> -D_GLIBCXX_USE_CXX11_ABI=0
> -O2
> -pipe
> -fstack-protector-strong
> --param=ssp-buffer-size=4
> -march=x86-64
> -mtune=generic
> -fPIC
> -fvisibility-inlines-hidden
> -Wall
> -W
> -Wno-unused-parameter
> -Wwrite-strings
> -Wcast-qual
> -Wmissing-field-initializers
> -pedantic
> -Wno-long-long
> -Wcovered-switch-default
> -Wnon-virtual-dtor
> -Wdelete-non-virtual-dtor
> -Werror=date-time
> -std=c++11
> -fcolor-diagnostics
> -ffunction-sections
> -fdata-sections
> -flto=thin
> -Wno-deprecated-declarations
> -Wno-unknown-pragmas
> -Wno-strict-aliasing
> -Wno-deprecated-register
> -Wno-vla-extension
> -O3
> -DNDEBUG
> -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu
> -flto=thin
> -Wl,-allow-shlib-undefined
> -Wl,-O3
> -Wl,--gc-sections \
>  tools/lldb/tools/driver/CMakeFiles/lldb.dir/Driver.cpp.o \
>  tools/lldb/tools/driver/CMakeFiles/lldb.dir/Platform.cpp.o
> -o bin/lldb-3.9.1
> -lpthread
> lib/liblldb.so.3.9.1
> -Wl,--start-group
> lib/liblldbBase.a
> lib/liblldbBreakpoint.a
> lib/liblldbCommands.a
> lib/liblldbDataFormatters.a
> lib/liblldbHost.a
> lib/liblldbCore.a
> lib/liblldbExpression.a
> lib/liblldbInitialization.a
> lib/liblldbInterpreter.a
> lib/liblldbSymbol.a
> lib/liblldbTarget.a
> lib/liblldbUtility.a
> lib/liblldbPluginDisassemblerLLVM.a
> lib/liblldbPluginSymbolFileDWARF.a
> lib/liblldbPluginSymbolFilePDB.a
> lib/libLLVMDebugInfoPDB.a
> lib/libLLVMDebugInfoCodeView.a
> lib/liblldbPluginSymbolFileSymtab.a
> lib/liblldbPluginDynamicLoaderStatic.a
> lib/liblldbPluginDynamicLoaderPosixDYLD.a
> lib/liblldbPluginDynamicLoaderHexagonDYLD.a
> lib/liblldbPluginDynamicLoaderWindowsDYLD.a
> lib/liblldbPluginCPlusPlusLanguage.a
> lib/liblldbPluginGoLanguage.a
> lib/liblldbPluginJavaLanguage.a
> lib/liblldbPluginObjCLanguage.a
> lib/liblldbPluginObjCPlusPlusLanguage.a
> lib/liblldbPluginObjectFileELF.a
> lib/liblldbPluginObjectFileJIT.a
> lib/liblldbPluginSymbolVendorELF.a
> lib/liblldbPluginObjectContainerBSDArchive.a
> lib/liblldbPluginObjectContainerMachOArchive.a
> lib/liblldbPluginProcessGDBRemote.a
> lib/liblldbPluginProcessUtility.a
> lib/liblldbPluginPlatformAndroid.a
> lib/liblldbPluginPlatformGDB.a
> lib/liblldbPluginPlatformFreeBSD.a
> lib/liblldbPluginPlatformKalimba.a
> lib/liblldbPluginPlatformLinux.a
> lib/liblldbPluginPlatformNetBSD.a
> lib/liblldbPluginPlatformPOSIX.a
> lib/liblldbPluginPlatformWindows.a
> lib/liblldbPluginPlatformMacOSX.a
> lib/liblldbPluginDynamicLoaderMacOSXDYLD.a
> lib/liblldbPluginUnwindAssemblyInstEmulation.a
> lib/liblldbPluginUnwindAssemblyX86.a
> lib/liblldbPluginAppleObjCRuntime.a
> lib/liblldbPluginRenderScriptRuntime.a
> lib/liblldbPluginLanguageRuntimeGo.a
> lib/liblldbPluginLanguageRuntimeJava.a
> lib/liblldbPluginCXXItaniumABI.a
> lib/liblldbPluginABIMacOSX_arm.a
> lib/liblldbPluginABIMacOSX_arm64.a
> lib/liblldbPluginABIMacOSX_i386.a
> lib/liblldbPluginABISysV_arm.a
> lib/liblldbPluginABISysV_arm64.a
> lib/liblldbPluginABISysV_i386.a
> lib/liblldbPluginABISysV_x86_64.a
> lib/liblldbPluginABISysV_hexagon.a
> lib/liblldbPluginABISysV_ppc.a
> lib/liblldbPluginABISysV_ppc64.a
> lib/liblldbPluginABISysV_mips.a
> lib/liblldbPluginABISysV_mips64.a
> lib/liblldbPluginABISysV_s390x.a
> lib/liblldbPluginInstructionARM.a
> lib/liblldbPluginInstructionARM64.a
> lib/liblldbPluginInstructionMIPS.a
> lib/liblldbPluginInstructionMIPS64.a
> lib/liblldbPluginObjectFilePECOFF.a
> lib/liblldbPluginOSGo.a
> lib/liblldbPluginOSPython.a
> lib/liblldbPluginMemoryHistoryASan.a
> lib/liblldbPluginInstrumentationRuntimeAddressSanitizer.a
> lib/liblldbPluginInstrumentationRuntimeThreadSanitizer.a
> lib/liblldbPluginSystemRuntimeMacOSX.a
> lib/liblldbPluginProcessElfCore.a
> lib/liblldbPluginJITLoaderGDB.a
> lib/liblldbPluginExpressionParserClang.a
> lib/liblldbPluginExpressionParserGo.a
> lib/liblldbPluginProcessLinux.a
> lib/liblldbPluginProcessPOSIX.a
> -Wl,--end-group
> lib/libclangCodeGen.a
> lib/libLLVMBitWriter.a
> lib/libLLVMCoverage.a
> lib/libLLVMipo.a
> lib/libLLVMVectorize.a
> lib/libLLVMIRReader.a
> lib/libLLVMAsmParser.a
> lib/libLLVMInstrumentation.a
> lib/libLLVMLinker.a
> lib/libLLVMObjCARCOpts.a
> lib/libLLVMObject.a
> lib/libLLVMScalarOpts.a
> lib/libLLVMInstCombine.a
> lib/libLLVMTarget.a
> lib/libLLVMTransformUtils.a
> lib/libLLVMAnalysis.a
> lib/libclangRewriteFrontend.a
> lib/libclangFrontend.a
> lib/libclangDriver.a
> lib/libclangParse.a
> lib/libLLVMMCParser.a
> lib/libLLVMProfileData.a
> lib/libLLVMOption.a
> lib/libclangRewrite.a
> lib/libclangSerialization.a
> lib/libclangSema.a
> lib/libclangAnalysis.a
> lib/libclangEdit.a
> lib/libclangAST.a
> lib/libclangLex.a
> lib/libclangBasic.a
> lib/libLLVMMC.a
> lib/libLLVMBitReader.a
> lib/libLLVMCore.a
> lib/libLLVMSupport.a
> -lrt
> -ldl
> -lcurses
> -lpthread
> -lz
> -lm
> -Wl,-rpath,"\$ORIGIN/../lib
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160927/15857ca7/attachment-0001.html>