search for: clang_version

...build, but that's what I just tried, and it still failed. Here's my install log: $ rm -rf ~/tmp/clang $ mkdir ~/tmp/clang; cd ~/tmp/clang $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm $ cd llvm/tools $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang $ cd ../.. $ export clang_version=235086 $ cd llvm/tools/clang/tools $ svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra $ cd ../../../.. $ cd llvm/projects $ svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt $ cd ../.. $ mkdir $HOME/clang-$clang_version $ mkdir build; cd build $ ../llvm/conf...

...iff: diff -uprN llvm-project-10.0.1rc1/clang/CMakeLists.txt llvm-project/clang/CMakeLists.txt --- llvm-project-10.0.1rc1/clang/CMakeLists.txt 2020-05-19 21:16:37.000000000 +0200 +++ llvm-project/clang/CMakeLists.txt 2020-05-20 18:36:57.621341162 +0200 @@ -358,8 +358,11 @@ endif() if(NOT DEFINED CLANG_VERSION_PATCHLEVEL) set(CLANG_VERSION_PATCHLEVEL ${LLVM_VERSION_PATCH}) endif() -# Unlike PACKAGE_VERSION, CLANG_VERSION does not include LLVM_VERSION_SUFFIX. -set(CLANG_VERSION "${CLANG_VERSION_MAJOR}.${CLANG_VERSION_MINOR}.${CLANG_VERSION_PATCHLEVEL}") +if(NOT DEFINED CLANG_VERSION_SUFFIX)...

...> > llvm-project/clang/CMakeLists.txt > > --- llvm-project-10.0.1rc1/clang/CMakeLists.txt 2020-05-19 > > 21:16:37.000000000 +0200 > > +++ llvm-project/clang/CMakeLists.txt 2020-05-20 18:36:57.621341162 +0200 > > @@ -358,8 +358,11 @@ endif() > > if(NOT DEFINED CLANG_VERSION_PATCHLEVEL) > > set(CLANG_VERSION_PATCHLEVEL ${LLVM_VERSION_PATCH}) > > endif() > > -# Unlike PACKAGE_VERSION, CLANG_VERSION does not include LLVM_VERSION_SUFFIX. > > -set(CLANG_VERSION > > "${CLANG_VERSION_MAJOR}.${CLANG_VERSION_MINOR}.${CLANG_VERSION_PATCHLE...

...s.txt ] if(NOT DEFINED LLVM_VERSION_SUFFIX) - set(LLVM_VERSION_SUFFIX "") + set(LLVM_VERSION_SUFFIX "rc1") endif() Unfortunately, clang-10 and ld.lld binaries did not show this in their version. So, I modified clang... [ clang/CMakeLists.txt ] -# Unlike PACKAGE_VERSION, CLANG_VERSION does not include LLVM_VERSION_SUFFIX. -set(CLANG_VERSION "${CLANG_VERSION_MAJOR}.${CLANG_VERSION_MINOR}.${CLANG_VERSION_PATCHLEVEL}") +if(NOT DEFINED CLANG_VERSION_SUFFIX) + set(CLANG_VERSION_SUFFIX ${LLVM_VERSION_SUFFIX}) +endif() +# CLANG_VERSION includes LLVM_VERSION_SUFFIX. +set(CLAN...

Hi Tom, thanks and congrats for LLVM 10.0.1-rc1 release. [1] shows 2 assets. 10.0.0 RCs had a lot of more assets. I am missing the llvm-project-10.0.1rc1.tar.xz tarball. Will you provide them later or is there a new development/workflow decision I do not know of? BTW, the source zip and tar.gz tarballs show no sizes. I am using Mobile LTE/UMTS to download stuff from the Internet. For now I

...ER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++ -DCMAKE_BUILD_TYPE=Release -DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config -DCOMPILER_RT_OUTPUT_DIR=${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION} -DCOMPILER_RT_INSTALL_PATH=lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION} # -DCOMPILER_RT_INCLUDE_TESTS=ON INSTALL_COMMAND "" ) add_dependencies(compiler-rt clang clang++ llvm-config) 1) Looks like "DEPENDS" option is just broken - docs here ( h...

On Tue, Jan 8, 2013 at 11:11 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 8 January 2013 18:40, Matthieu Monrocq <matthieu.monrocq at gmail.com> > wrote: >> >> I do believe it's undefined. >> >> §5.2.1 Subscripting [expr.sub] >> ... >> §5.7 Additive operators [expr.add] >> ... > > > Still, doesn't explicitly

On Thu, Feb 6, 2014 at 7:57 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > > Le 6 févr. 2014 à 16:20, Brad King <brad.king at kitware.com> a écrit : > > > On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > >> Please note that it makes a lot of sense to built compiler-rt (and > sanitizers) with just-built > >> Clang. In fact, even though we

...ild drops the ${arch} suffix from its libs, and >> >> the "clang/runtime" build uses CMAKE_INSTALL_PREFIX to control where >> >> the compiler-rt libs go. >> >> >> >> >> "CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux" >> >> >> >> >> >> 4) Remove multi-arch support from the compiler-rt build. Instead, >> >> declare compiler-rt as an "any-arch" build, configured with: >> >> CMAKE_CXX_COMPILER (defaults to just-built-clan...

...) The compiler-rt build drops the ${arch} suffix from its libs, and > >> the "clang/runtime" build uses CMAKE_INSTALL_PREFIX to control where > >> the compiler-rt libs go. > >> > >> > "CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux" > >> > >> > >> 4) Remove multi-arch support from the compiler-rt build. Instead, > >> declare compiler-rt as an "any-arch" build, configured with: > >> CMAKE_CXX_COMPILER (defaults to just-built-clang) > >>...

On 8 January 2013 18:40, Matthieu Monrocq <matthieu.monrocq at gmail.com>wrote: > I do believe it's undefined. > > §5.2.1 Subscripting [expr.sub] > ... > §5.7 Additive operators [expr.add] > ... > Still, doesn't explicitly say it's undefined. I agree this gives the freedom of implementers to extend naturally, but it's at least arguable. I have the 2011

...and once for > i386 libs. > > 3) The compiler-rt build drops the ${arch} suffix from its libs, and > the "clang/runtime" build uses CMAKE_INSTALL_PREFIX to control where > the compiler-rt libs go. > > "CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux" > > 4) Remove multi-arch support from the compiler-rt build. Instead, > declare compiler-rt as an "any-arch" build, configured with: > CMAKE_CXX_COMPILER (defaults to just-built-clang) > CMAKE_CXX_FLAGS (defaults to llvm's default target) &...

...gt;>>> >> the "clang/runtime" build uses CMAKE_INSTALL_PREFIX to control where >>>> >> the compiler-rt libs go. >>>> >> >>>> >> >>>> >> "CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux" >>>> >> >>>> >> >>>> >> 4) Remove multi-arch support from the compiler-rt build. Instead, >>>> >> declare compiler-rt as an "any-arch" build, configured with: >>>> >> CMAKE_C...

It does sound like Android is better suited for "honest" cross-compilation, rather than "build compiler-rt for all targets we can find" model. I'm still not convinced that we must require the "ninja install" step. Could we just "ninja clang" and then build the second stage against the first stage build directory? Will this "find_package" thing

...>>>> >> where >> >>>> >> the compiler-rt libs go. >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> "CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux" >> >>>> >> >> >>>> >> >> >>>> >> 4) Remove multi-arch support from the compiler-rt build. Instead, >> >>>> >> declare compiler-rt as an "any-arch" build, configured with: &...