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 > env DYLD_LIBRARY_PATH=$BUILD_COMPILER/lib/ \ > cmake \ > -G Ninja \ > -DCMAKE_BUILD_TYPE=${type} \ > -DLLVM_BINUTILS_INCDIR=$BINUTILS/include \[...]> -DCMAKE_C_FLAGS=${cflgs} \ > -DCMAKE_CXX_FLAGS=${cflgs} \ > -DCMAKE_EXE_LINKER_FLAGS=${linkflgs} \ > $SRCIs 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/includeCurious, is your host binutils too old for that to exist in /usr/include?> 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.
On Tue, Sep 27, 2016 at 11:27 AM, Carsten Mattner <carstenmattner at gmail.com> wrote:> 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 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.> > > 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 > > env DYLD_LIBRARY_PATH=$BUILD_COMPILER/lib/ \ > > cmake \ > > -G Ninja \ > > -DCMAKE_BUILD_TYPE=${type} \ > > -DLLVM_BINUTILS_INCDIR=$BINUTILS/include \ > [...] > > -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? >Yes. The version mentioned at the top: clang version 3.9.1 (branches/release_39 281767)> > 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? >Not sure I followed that, but in essence you just want to make sure that llvm-ranlib and llvm-ar match the build compiler.> > > 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 > /usr/include? >I guess - I always use my own version of binutils.> > > 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? >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.> > > 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). >Ok> > > 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. >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. 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? Teresa -- 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/cffca6ea/attachment.html>
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. 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.> 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 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?> 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