similar to: [LLVMdev] [PATCH] Prevent CMake from installing libgtest*.

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM 3.2 (with clang, extras, and compiler-rt) building - but not testing - on Xcode. I used CMake 2.8.10 GUI to create the Xcode project file. Below are my notes. First, I believe CMake ends up setting things up so that Xcode has 1 warning after scanning the project having to do with hires images or some such… it takes

Those look like the linker is being passed the same .o file built twice, ex: ../Objects-normal/x86_64/asan_globals_test.o ../lib/asan/tests/asan_globals_test.cc.asan.o So, the symbols are colliding. Something is set up wrong in the xcode project. -Nick On Dec 19, 2012, at 9:48 AM, Relph, Richard wrote: > Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM

Hi Richard! On Thu, Dec 20, 2012 at 12:48 AM, Nick Kledzik <kledzik at apple.com> wrote: > Those look like the linker is being passed the same .o file built twice, > ex: > ../Objects-normal/x86_64/asan_globals_test.o > ../lib/asan/tests/asan_globals_test.cc.asan.o > > So, the symbols are colliding. Something is set up wrong in the xcode > project. > > -Nick

Different, but still failing (this time with Xcode 4.4…) /Users/rrelph/llvm/tot/xcode/bin/Debug/clang sanitizer_allocator_test.cc.i386.o sanitizer_common_test.cc.i386.o sanitizer_flags_test.cc.i386.o sanitizer_libc_test.cc.i386.o sanitizer_list_test.cc.i386.o sanitizer_printf_test.cc.i386.o sanitizer_stackdepot_test.cc.i386.o sanitizer_test_main.cc.i386.o gtest-all.cc.i386.o

Please don't be alarmed by the failed compiles on llvm-ppc-darwin. They are likely not your fault. I'm trying to get a PPC build bot setup (arxan_bellini), and so far it's dying here: Linking CXX shared library ../../lib/libgtest.dylib Undefined symbols: "vtable for llvm::raw_ostream", referenced from: __ZTVN4llvm11raw_ostreamE$non_lazy_ptr in gtest.cc.o

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

Moving to llvm-dev (I think this has gone a bit further than a patch review discussion) In hindsight I probably should have explained more of my thinking on this with the patch, or done an RFC on llvm-dev to start with. I’l do that now, and answer the questions along the way. I sent a separate email discussing Justin’s patch review feedback. In the build system today there is no strong

Hey Ben, Thank you for providing this feedback. I’m going to lay out some ideas that I have inline below. > On Jun 9, 2016, at 11:26 AM, Craig, Ben via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm great with moving the runtimes into their own directory and making cmake modules to standardize an interface between the LLVM build process and the runtime build process. I

Hi, I found that building LLVM in single-threaded mode with CMake is failing because some object files still have references to pthread routines. There are two instances of the build failure happening. $ cmake .../llvm/ -DLLVM_ENABLE_THREADS=0 $ make -j8 check-all % Linking CXX executable IRTests ../../lib/libgtest.a(gtest.cc.o): In function

It seems to me that the feedback here has been generally positive, but a lot of different ideas have been added to the mix. To focus conversation and move things along I'm going to provide a summary of changes with proposals for rollout. Splitting Compiler-RT If we want to split compiler-rt, which I think makes a lot of sense, I think the best path forward is to copy the trunk (via svn cp).

Hi, In another post I was trying to find out how to use libc++ instead of libstdc++ when compiling llvm/clang. I couldnt find the a way to tell cmake to do that. So I switched to using configure to compile llvm/clang. But now I find that the artifacts produced are different. Here are the issues I see: - configure doesnt seem to respect '--prefix' option, it just puts

We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward. Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note

On Thu, Mar 26, 2020 at 11:48 PM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Mar 26, 2020 at 9:07 PM Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which

Assuming this is a one-time version bump, this seems reasonable to me. Perhaps this goes without saying, but the warning for point 1 should only happen if you don’t have CMake >= 3.13.4 installed. It sounded to me from your original message that you have an urgent need to upgrade to 3.8. Were you planning on going ahead with that right away? From: llvm-dev <llvm-dev-bounces at

I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way. Some things it might be worth figuring out for future upgrades: * If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)? * For platforms like Ubuntu

Ubuntu 20.04 LTS will be released soon, and I believe it’ll have CMake 3.16.3, so that increases the LTS lower bound significantly. I strongly disagree with the sentiment that the build system already works so there’s no urgent need to improve it. I believe we should treat the build system like code, and the same ideas around refactoring apply. Our build system is a huge thorny mess; there’s tons

Hi Zachary: I was able to reproduce the greendragon results locally (OSX), and fix the problem by excluding 'debuginfo-tests' from check-clang -- this prevents them from being added twice, once for check-clang and again for check-debuginfo. Below are the minimized patches I used to reproduce and fix the problem -- based on your originals. I've verified these patches work when

> On Dec 6, 2017, at 10:21 AM, Zachary Turner <zturner at google.com> wrote: > > Can I have some assurance that if it fails again, someone will look into who has access to the builders so I don't have to keep doing speculative commits? Sure. I did this last time and I promise to also do it this time. -- adrian > > On Wed, Dec 6, 2017 at 10:13 AM Adrian Prantl

> On Dec 6, 2017, at 10:10 AM, Zachary Turner <zturner at google.com> wrote: > > Adrian, Mike, Chris? Any update on this? I've temporarily switched to working on something different, but I plan to be back on this in a couple of weeks. It's been a month since my first revert of this CL, which seems like a reasonable amount of lead-time to deal with issues surrounding