[llvm-dev] (Thin)LTO llvm build

Tue Dec 20 06:10:58 PST 2016

On Tue, Dec 20, 2016 at 5:49 AM, Carsten Mattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi again, Teresa.
>
> Looks like I had forgotten to report back with success
> when finally building 3.9.0 in ThinLTO linker mode
> back in October. Sorry about that and thanks for
> helping me out. I know how important it is to get
> success reports as well, as a developer myself,
> so sorry again :(.
>
> While that worked back then, last weekend I tried to
> build 3.9.1 using 3.9.0 as installed from Arch Linux
> and ran into a familiar issue but in another module.
> I was using the Arch Linux package because it worked
> the last time and without something like a chroot,
> I cannot build 3.9.1 with personal-3.9.0 and then
> overwrite it with the new build because the ninja
> scripts hard-code paths to CC and CXX which then
> ends in an error.
>
> I tried twice, and before I try another build,
> I wonder about this:
>
> - Should I avoid any and all CFLAGS, CXXFLAGS, CPPFLAGS,
>   LDFLAGS in favor of passing these exclusively as
>   cmake's -Dsomething_something=<FLAGS>? Linux distros
>   usually have an environment with CFLAGS etc. and use
>   that building packages and this didn't interfere in the
>   past in my builds, but I'm open to avoid this by unsetting
>   any such variables first.
>
> - Is there a configuration in the CI matrix that builds all
>   of LLVM with ThinLTO so that I can be reasonably sure
>   any error is most likely local to my environment or
>   because of operator (silly me) faults?
>
> $ svn info
> URL: http://llvm.org/svn/llvm-project/llvm/branches/release_39
> Relative URL: ^/llvm/branches/release_39
> Repository Root: http://llvm.org/svn/llvm-project
> Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
> Revision: 290054
> Node Kind: directory
> Schedule: normal
> Last Changed Author: tstellar
> Last Changed Rev: 288847
>
>
> I also pass these in LDFLAGS but they're not visible
> in the error trace below:
>     -Wl,-plugin-opt,-function-sections \
>     -Wl,-plugin-opt,-data-sections \
>
> Any idea why lldb-argdumper would fail to link reproducably?
>
> $ ninja
>
> [...]
>
> [3480/3688] Linking CXX executable bin/lldb-argdumper
> FAILED: bin/lldb-argdumper
> : && /usr/bin/clang++ -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
> -fuse-ld=gold
> -flto=thin
> -Wl,-allow-shlib-undefined
> -Wl,-O3
> -Wl,--gc-sections
> tools/lldb/tools/argdumper/CMakeFiles/lldb-argdumper.dir/argdumper.cpp.o
> -o bin/lldb-argdumper -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" && :
>
> /usr/bin/ld.gold: bin/lldb-argdumper: hidden symbol `__morestack' in
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.2.1/libgcc.a(morestack.o)
> is referenced by DSO
>
> /usr/bin/ld.gold: final link failed: Bad value
>
> clang-3.9: error: linker command failed with exit code 1 (use -v to
> see invocation)
>
> ninja: build stopped: subcommand failed.
>

Can you try and see if this reproduces with lld? You should be able to
pass `-fuse-ld=lld` to the invocation instead of `-fuse-ld=gold`. You
don't need a plugin.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare