search for: add_library

Hi, I am trying to make my pass compiling inside the LLVM tree or outside. It works when I include my pass inside the tools folder, however when I try to compile it outside the LLVM tree I get the following error: "add_library cannot create target "LLVMTarget" because an imported target with the same name already exists.” It happens when I’ve already compiled and installed my target from within LLVM. I was wondering if there is a way to ignore that and just overwrite the target. Thanks. Best, Simone

...ludes a working CI set-up, so that you can be confident that it > works. If it doesn't, ping me - I'm keen on improving it. Cool, thanks. I just started reading over that now. I have a couple of questions already, if you don't mind: 1) I see you're building the pass with add_library(lt-cc-static STATIC StaticCallCounter.cpp DynamicCallCounter.cpp) add_library(lt-cc-shared MODULE StaticCallCounter.cpp DynamicCallCounter.cpp) What's the reason for building a STATIC version? Does any LLVM tool make use of that? Is add_library the preferred pass-building CMake mac...

...or LLVM 3.8 though. Thanks for pointing that out. I had actually recently stumbled across that page (and the GitHub repository it references, https://github.com/sampsyo/llvm-pass-skeleton) while searching for an answer to my questions but wasn't sure how up-to-date the information is: * Is add_library the currently recommended CMake macro call for building an LLVM pass? http://llvm.org/docs/WritingAnLLVMPass.html and https://llvm.org/docs/CMake.html both point to add_llvm_library, which I couldn't get to work. * Is the legacy pass manager still the right way to make a pass...

...against the LLVM libraries, and so what happens is that the various command-line objects, which are statically constructed, are getting loaded twice, once for the tool itself, and once for the plugin. However, I'm not sure how to create my plugin any differently. I'm using cmake's 'add_library(name SHARED ...)' to create the plugin like so: add_library(reflector SHARED ${REFLECT_SOURCES} ${COMMON_HEADERS} ${REFLECT_HEADERS}) target_link_libraries(reflector linker_common ${LLVM_TARGET} ${LLVM_CORE} ${LLVM_SUPPORT} ${LLVM_SYSTEM} ) Any advice on this? -- --...

Hi Dean, For me the build is still broken: -- Builtin supported architectures: i386;x86_64;x86_64h CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): add_library cannot create target "RTXRay.test.osx" because another target with the same name already exists. The existing target is a static library created in source directory "/Volumes/Transcend/code/llvm/projects/compiler-rt/lib/xray/tests". See documentation fo...

...es, and so what happens is > that the various command-line objects, which are statically constructed, are > getting loaded twice, once for the tool itself, and once for the plugin. > > However, I'm not sure how to create my plugin any differently. I'm using > cmake's 'add_library(name SHARED ...)' to create the plugin like so: > > add_library(reflector SHARED ${REFLECT_SOURCES} ${COMMON_HEADERS} > ${REFLECT_HEADERS}) > target_link_libraries(reflector > linker_common > ${LLVM_TARGET} > ${LLVM_CORE} > ${LLVM_SUPPORT} > ${LLVM...

...> On Apr 11, 2018, at 10:50 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > Hi Dean, > > For me the build is still broken: > > -- Builtin supported architectures: i386;x86_64;x86_64h > CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): > add_library cannot create target "RTXRay.test.osx" because another target > with the same name already exists. The existing target is a static library > created in source directory > "/Volumes/Transcend/code/llvm/projects/compiler-rt/lib/xray/tests". See &g...

...OK, I'm just going to paste in my CMakeLists.txt file. Like I said, > I'm building an LLVM install myself by untarring llvm, mkdir build in > the root dir of the source, cd build/, cmake .., make. > >> cmake_minimum_required (VERSION 2.6) >> project (libjllvm) >> add_library(jllvm Analysis_wrap.c BitReader_wrap.c BitWriter_wrap.c >> Core_wrap.c EnhancedDisassembly_wrap.c ExecutionEngine_wrap.c >> LinkTimeOptimizer_wrap.c lto_wrap.c Target_wrap.c >> Transforms/IPO_wrap.c Transforms/Scalar_wrap.c) >> >> # A convenience variable: >> set...

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 go...

...re the note at https://cmake.org/cmake/help/latest/command/file.html#glob ? Q3: The C files were not extracted/reconstructed with execution in mind. For now, we're mainly interested in collecting stats and testing the compiler. Since we don't generate executables, should I call cmake's add_library() for each .c file? Kind regards, Bruno Kind -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200406/0c5478bb/attachment.html>

On 9/18/2017 8:20 PM, Diptorup Deb via llvm-dev wrote: > Hi, > > We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the > upgrade our module works when built with an LLVM Debug build, but > with an LLVM Release build we are encountering the following error. > > This happens after our passes have successfully run. I believe this > has to do with the way our

...es.h" >> make[2]: *** [CMakeFiles/jllvm.dir/Analysis_wrap.c.o] Error 1 >> make[1]: *** [CMakeFiles/jllvm.dir/all] Error 2 >> make: *** [all] Error 2 Yes, you must define __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS on your CMakeLists.txt. Put this before any add_executable/add_library that contains source files that uses LLVM stuff: add_definitions( -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS )

...rgen On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Steve, excuse me to respond you partially. > > 2014-02-10 18:54 GMT+09:00 Stephen Kelly <steveire at gmail.com>: >> 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 w...

...ose files be included in "normal" builds, or will LLVM switch to CMake as its primary build system?). Now I'm running into the problem of cflags or includes or something not being set properly. CMakeLists.txt: > cmake_minimum_required (VERSION 2.6) > project (libjllvm) > add_library(jllvm Analysis_wrap.c BitReader_wrap.c BitWriter_wrap.c > Core_wrap.c EnhancedDisassembly_wrap.c ExecutionEngine_wrap.c > LinkTimeOptimizer_wrap.c lto_wrap.c Target_wrap.c > Transforms/IPO_wrap.c Transforms/Scalar_wrap.c) > > # A convenience variable: > set(LLVM_ROOT "/usr...

...:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> >> Steve, excuse me to respond you partially. >> >> 2014-02-10 18:54 GMT+09:00 Stephen Kelly <steveire at gmail.com>: >> >> 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...

Hi, We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the upgrade our module works when built with an LLVM Debug build, but with an LLVM Release build we are encountering the following error. This happens after our passes have successfully run. I believe this has to do with the way our passes are registered. Would greatly appreciate some pointers, as to where to look. Program

...in agx-ast-addons/trunk/spandsp-0.0.4/CMakeLists.txt as the content of this file is: project (app-fax-span4) # ------------------------------------------------------ # Target # we use "MODULE" cause it build a shared object module # ------------------------------------------------------ ADD_LIBRARY(app_fax???????????????????? MODULE app_fax.c) # # We remove the "lib" prefix from the libmodule.so filename # SET_TARGET_PROPERTIES(app_fax?????????? PROPERTIES PREFIX "") # # We add library dependencies to use those modules # TARGET_LINK_LIBRARIES(app_fax spandsp tiff) # # o...

...t; make[2]: *** [CMakeFiles/jllvm.dir/Analysis_wrap.c.o] Error 1 >>> make[1]: *** [CMakeFiles/jllvm.dir/all] Error 2 >>> make: *** [all] Error 2 > Yes, you must define __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS on > your CMakeLists.txt. Put this before any add_executable/add_library that > contains source files that uses LLVM stuff: > > add_definitions( -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS )

...T_FILE:SomeTool> generator expression to > get the location in a well-defined manner. It works in > add_custom_command so that should be sufficient for your example > use case. I've taken another look at this. For the simple example project [1] I'm effectively doing this. ``` add_library(ReplaceGetGlobalID MODULE ReplaceGetGlobalID.cpp) get_property(MODULE_FILE TARGET ReplaceGetGlobalID PROPERTY LOCATION) configure_file(run.sh.in run.sh @ONLY) ``` where run.sh is a simple shell script to demonstrate how to invoke the built library as a plug-in to the opt tool. With this CMP0026 p...

On Fri, 2005-10-21 at 18:54 +0000, Xen patchbot -unstable wrote: > # HG changeset patch > # User kaf24@firebug.cl.cam.ac.uk > # Node ID 8eaaa622db81393ef0eae497090c34c04adf4212 > # Parent 3eee5653f08b01a310e0a9172a6c0149f16217df > Tweak to pygrub build config detection. > Signed-off-by: Jeremy Katz <katzj@redhat.com> Applying both patches for this is overkill.... ;)