search for: target_link_library

...ked this in locally for clang and confirmed that it made the install(EXPORT) CMake errors go away. Unfortunately, cmake also requires all instances of target_link_libraries for a particular target to use either the legacy or the non-legacy signature, and it turns out all our uses of target_link_library for executables are using the legacy signature right now, so this would have to be a substantial cross-repository change in order to avoid breaking the world. I'm fine with taking the work on, but I wanted to confirm my approach before putting that work in. Thanks, Shoa...

I was a bit confused with what the difference was between the old target_link_libraries(foo bar) and the new target_link_libraries(foo INTERFACE|PRIVATE|PUBLIC bar) To try to find out, I decided to look at the generated build.ninja. The difference that shows up is far fewer order only dependencies. For example build lib/TableGen/CMakeFiles/LLVMTableGen.dir/Error.cpp.o: CXX_COMPILER

On Thu, Oct 31, 2013 at 12:17 PM, Sebastian Pop <spop at codeaurora.org> wrote: > Is there a reason to not use the cmake add_dependencies to establish the link > order of the LLVM libs instead of using the LLVMBuild.txt info? Have you tried `target_link_libraries`? The new CMake book has an example showing one static lib depending on another (page 25): `target_link_libraries(foo

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

Hi, I've been working on a set of patches to statically link polly in the LLVM tools. There remains an error I can't seem to solve when linking llvm-lto (all other tools luckily get linked correctly): it insists adding libLLVMipo.a after libLLVMPolly.a on the link command, resulting in an error of the form: PassManagerBuilder.cpp:(.text+0x499): undefined reference to

Description =========== This patch adds support of CMake meta build system, so you can generate Unix makefiles, VS 6.0-2017 projects and many more. Features ======== * Win32 and Linux tested * Travis CI test added * Generates working Visual Studio 6.0-2017 solutions * Generates working Unix Makefile * Supported options (<option> - <default value>): * `ENABLE_FLOATING_POINT` - on

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

Hello, this is a question, concerning cmake lists configuration. I am trying to link together two llvm passes, but they still should be as two modules. So: passA - A.so passB - B.so passB should use passA , so I sould use target_link_libraries ( and of course, I have included useAnalysis in passB) . But I can't link libraries that are build as Modules, so I tried to create two libraries at

I just copy the latest code in HowToUseJIT and run, but the EngineBuilder(std::move(Owner)).create() keeps return null, any idea why? Here's my CMakeList: cmake_minimum_required(VERSION 3.12) project(llvm_test) set(CMAKE_CXX_STANDARD 14) find_package(LLVM REQUIRED CONFIG) llvm_map_components_to_libnames(llvm_libs support core irreader orcjit native) add_executable(llvm_test main.cpp)

While implementing the object file library I ran into some weird linking issues. It turned out that you have to manually specify extra library dependencies in LLVMLibDeps.cmake, along with what you already specify in the CMakeLists.txt file for the component. The attached patches remove this requirement, and add real CMake package export capabilities. A CMake user wishing to use LLVM can now use

I found a private ErrorStr member, but didn't find the get function of this member, could you tell me how I can get the error message? On Wed, Sep 18, 2019 at 4:02 PM mayuyu.io <admin at mayuyu.io> wrote: > Isn’t there a method in EngineBuilder to get the error message or > something? > I assume it’s you didn’t link in the JIT module > > Zhang > > 在

Hi, I am brand new to LLVM, or more precisely, trying to be. I'm getting stuck on compiling LLVM. - I tried installing on a Mint 18.1 VM with 6GB RAM, and the builds of some large executables were killed by the OOM killer. I finally realized that I needed to build using shared libraries, and succeeded. This was in November. - I put aside my LLVM project, and just got back to it. I got stuck

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

This is useful for developer who uses multicore builder. https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes - The Ninja <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on

On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > I'll have another look tomorrow. Thanks. > IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution: Fair enough. I've never

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

Reviving the discussion. The cool cmake-build of compiler-rt is not completely functional, but allows sanitizer runtimes to reuse LLVM code with almost no dirty hacks. Suppose I want to run call functions from LLVM libs (currently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime. 1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime

Hi, Attached is small patch (based of r122998 of compiler-rt), required for clean builds on Solaris 10 / x86 using clang 2.8. Please consider it for inclusion. Cheers, Joakim -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris_stdint.patch Type: application/octet-stream Size: 457 bytes Desc: not available URL:

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

Hello all, One of the common patterns in CMake 3.x is the "superbuild" pattern, where the source trees of a dependencies are nested under a master project. In order for the projects to be modular (be agnostic to whether or not the dependencies are nested or not), the in-tree build process needs to generate the same targets as finding the dependencies out of tree. For example: