similar to: [LLVMdev] Some CMake issues (Are you being served?)

With reference to the following thread: http://lists.llvm.org/pipermail/llvm-dev/2016-January/094100.html I am having the same issue. First I did a git pull of all the relevant directories and then doing a cmake: cmake -DLLVM_ENABLE_DOXYGEN=ON -DLLVM_ENABLE_WERROR=OFF -DLLVM_TARGETS_TO_BUILD="X86" ../llvm and followed by make: [ 22%] Built target LLVMVectorize [ 25%] Built target

Hi, The test-suite expects to be built standalone but it looks like you have it in the same tree as LLVM. You'll need to remove it. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Teoh via llvm-dev Sent: 28 February 2016 14:31 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] [cfe-dev] [3.8 Release] We have branched With reference to the following thread:

I think we've just forgotten to update that part of the instructions. Having the test-suite at projects/test-suite was harmless to the old autoconf and LLVM 3.7.x's cmake builds because it didn't actually cause the test-suite to be built. The CMakeLists.txt that have been added to the test-suite now cause it to be built by LLVM's build system which introduces the build failure. We

On 2 Feb 2014, at 17:42, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> 6) If you create a proper config file, then you can populate it with >> IMPORTED targets and use it in clang. IMPORTED targets record dependencies >> and usage requirements (when you start requiring CMake 2.8.9+ at least) >> properly. >> >>

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) @@

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

Alright, this version works for me. Anything else that needs to be done? -Alex > On Oct 7, 2015, at 8:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake > index 452a728..cb06450 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,15 @@

It should probably be inside an `if(LLVM_USE_HOST_TOOLS)` block. That way the extra target and command won’t get added unless needed and CMake won’t spew dev warnings. Adding a target with a nonexistent dependency makes CMake dump a bunch of developer warnings. Other than that this looks good. Does it resolve the issue for you? -Chris > On Oct 7, 2015, at 4:09 PM, Alex Wang <aw1621107 at

Looks good to me! I can commit this for you today. Thanks! -Chris > On Oct 19, 2015, at 2:40 PM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks like the LLVMSupport patch didn't get everything -- build failed in the > same way on libLLVMTableGen. Problem/solution looked the same as for > LLVMSupport, so just tweaked the previous patch, and

NAKAMURA Takumi wrote: > [CMake] Introduce llvm_add_library(). I recommend moving away from wrappers like this. They indicate that either CMake is not providing the interfaces needed, or not propagating them, or that they exist but are not used. Such wrappers don't parse the arguments in the same way as the wrapped command etc. Wrappers are not good API proxies. Additionally, you put

Hello, thank you for the thoughts. > Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem > especially)? They certainly aren't perfect but they are considerably > better than what was there before. Okay, the documentation has come a long way since 3.0 although it still needs a bit of polish. > I wouldn't say that much "important functionality is plain

On 17/05/16 22:38, Tim Northover wrote: > Compiler-rt is the equivalent of libgcc, and Clang can use the > existing host's libgcc quite happily so it's really not that important > unless you're trying to build a GNU-free environment for whatever > reason. > Thanks Can you tell me how I would go about telling the cmake buildsystem (which is what the Debian packaging

Hi Takumi, I am not sure if it this change, but recently we started to build LLVMHello.so and BugpointPasses.so on OS X. A few bugpoint tests are failing, because they are looking for a dylib that doesn’t exist. Could you please take a look? Thanks -Juergen On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Steve, excuse me to respond you partially. >

The Asterisk Development Team would like to announce the release of Asterisk 16.0.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 16.0.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following issues are resolved in this release:

No, it has the wrong value. I tried it with cmake 2.8.9 and 2.8.12.2. Both of them set the variable to “.so”. On Feb 12, 2014, at 5:29 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Juergen, > > Thanks to let me know. I guess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake;

Hi Philip, thanks for the quick answer. That makes sense, but when leaving the set LLVM_LINK_COMPONENTS out I get an undefined symbol when loading the plugin: _ZTVN4llvm2cl3optINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEELb0ENS0_6parserIS7_EEEE which boils down to llvm::cl::opt<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>,

Hi, I have a dynamically loaded llvm pass built in-tree with ninja (generated with cmake, basically a copy of the hallo pass plugin, linux, llvm/clang version 6.0.1). It uses the ExecutionEngine. Building it without linking against LLVMExecutionEngine library results in an undefined symbol to the vtable of the EngineBuilder when loaded to opt. Linking the plugin with LLVMExecutionEngine results in

I am using LLVM as back end for my compiler, and until now I have used my own CMake build system for LLVM. But now LLVM has a CMake build system of its own, so when upgrading my LLVM version I decided to move to the 'official' one. It's not an easy transition, the build fails. I already found one bug: in some files the variable CMAKE_SOURCE_DIR is used for the LLVM top-level source

Hi, I'm working on an LLVM Pass plugin and I'm running into a problem when loading it into opt. I want to have a custom option for my pass and added an llvm::cl::opt #include'ing "llvm/Support/CommandLine.h" linking the dependant libs causes the following error when loading it with opt: opt: CommandLine Error: Option 'debug-pass' registered more than once! I

> On Oct 5, 2015, at 9:37 AM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Probably should have checked earlier... Do patches go directly to llvm-commits for review instead of getting reviewed here first? > > ccing llvm-commits too in case >> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com> wrote: >> >> Alright, got