I am trying to develop an llvm pass under my project directory. For that, I follow the info in http://llvm.org/docs/CMake.html#developing-llvm-pass-out-of-source. I create my CMakeFiles appropriately as in this link and my final project directory is like;
|-- src
| |-- CMakeLists.txt
| |-- bigForPass
| | |-- CMakeLists.txt
| | |-- bigForPass.cpp
| | |-- merged.bc
| |-- build
I also linked my source files with llvm root directory without any problem.
Finally I make the build under the 'build' folder and my shared library is created successfully with no problems (under build/bin folder) with the name LLVMHello1.dylib.
However, when I try to run my pass over merged.bc file (which contains my llvm code) with the command
opt -load ../build/bin/LLVMHello1.dylib -bishe_insert <merged.bc> final.bc
I keep getting the error;
Error opening '../build/bin/LLVMHello1.dylib': dlopen(../build/bin/LLVMHello1.dylib, 9): Symbol not found: __ZTIN4llvm10ModulePassE
Referenced from: ../build/bin/LLVMHello1.dylib
Expected in: flat namespace
in ../build/bin/LLVMHello1.dylib
-load request ignored.
Any ideas and suggestions on this appreciated ?
Thanks a lot in advance.
from http://www.jiang925.com/node/28
Undefined Symbol: _ZTIN4llvm12FunctionPassE There is an inconsistency
between LLVM main build system and the cmake support for building
out-of-source. The LLVM binaries are built without runtime type info
"-fno-rtti". Therefore, the out-of-source passes have to be built the
same way otherwise opt will complain that symbol
"_ZTIN4llvm12FunctionPassE" is undefined.
To solve this problem, LLVM must be compile with RTTI enabled. Add
"-DLLVM_REQUIRES_RTTI=1" to cmake, or add "REQUIRES_RTTI=1" to make.
So I added SET(CMAKE_CXX_FLAGS "-Wall -fno-rtti") to CMakeLists.txt of my pass library and then it's working.
Related
I am trying to build a project with numerous dependencies such as Boost, OpenSSL, and C++ REST SDK. However, it is required that the source code is included in the project workspace and that the library is built from said source code.
The most consistently successful way I have found to achieve this is though the use of git submodule add <URL>, add_subdirectory, target_link_libraries, and some clever projects built for this purpose such as boost-cmake and openssl-cmake.
Take for example the following project structure:
prjct
| include/
| libs/
| | boost-cmake/
| | openssl-cmake/
| | cpprestsdk/
| src/
| tests/
| CMakeLists.txt
For which the top-level CMakeLists.txt would contain:
...
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/libs/boost-cmake)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/libs/openssl-cmake)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/libs/cpprestsdk)
target_link_libraries(${PROJECT_NAME_L}
PUBLIC
Boost::system
Boost::thread
Boost::log
Boost::program_options
Boost::chrono
ssl # OpenSSL::SSL
crypto # OpenSSL::Crypto
cpprestsdk::cpprest
)
...
However, in the case of the cpprestsdk library, I recieve the following error upon running cmake .. from build/:
CMake Error at CMakeLists.txt:55 (add_library):
Target "prjct" links to target "cpprestsdk::cpprest" but the target
was not found. Perhaps a find_package() call is missing for and IMPORTED
target, or an ALIAS target is missing?
How can I link and use the C++ REST SDK within these constraints?
I compiled a executable file that is linked to a some library a.dyld on Mac OS, which is located in /mylib using cmake.
When I tried to run the program, the error message comes:
dyld: library not loaded a.dyld
Referenced from: path the executable file belongs
Reason: imagh not found.
So, if I set the environment variable $DYLD_LIBRARY_PATH to /mylib, the program works correctly.
But I dont want to do that since it forces every executable files to lookup the same library. (I have multiple libraries of the same name in many directories where each directory name specifies the functionality of the library.)
Is it possible to set $DYLD_LIBRARY_PATHfrom cmake??
Say, I have a multiple directories like
test_project
|--CMakeLists.txt
|--/src
|--CMakeLists.txt (build b.dyld)
... (programs for b.dyld)
|--/run_test1
|-- CMakeLitsts.txt (link b.dyld, and a.dyld under /mylyb1)
|-- (programs to be run)
|--/run_test2
|-- CMakeLitsts.txt (link b.dyle, and a.dyld under /mylyb2)
|-- (programs to be run)
... (/run_testN)
I'm trying to add a feature as a sub-library to
an existing application. But I met troubles of install(EXPORT ...)
My project source code structure shows as below:
app (the existing application)
|-- top-level CMakeLists.txt
|
|-- sublib (my new feature)
| |-- src
| |-- include
| `-- CMakeLists.txt
|
|-- other existing src ...
I build sublib in the CMakeLists.txt inside my own feature as:
add_library(sublib ${LIB_SRC})
I modify the top-level CMakeLists.txt in the existing application to
link sublib:
add_subdirectory(subdirectory of sublib)
...
target_link_directories(app sublib)
I thought it was enough. But CMake threw out an error:
CMake Error: install(EXPORT "appTargets" ...) includes target "app"
which requires target "sublib" that is not in the export set.
I guess it is because app itself is exported by install(EXPORT .. ) in the
top-level CMakeLists.txt. Thus I also try to install and export sublib.
I add the install and export into sublib CMakeLists.txt:
install(TARGETS sublib
EXPORT sublibTargets
ARCHIVE DESTINATION ${BIN_INSTALL_DIR}
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
RUNTIME DESTINATION ${LIB_INSTALL_DIR}
)
install(EXPORT sublibTargets
FILE sublib-config.cmake
DESTINATION ${LIB_INSTALL_DIR}/cmake/sublib
)
I then add find_package() in top-level CMakeLists.txt:
find_package(sublib REQUIRED)
target_link_directories(app sublib)
However, it becomes worse. sublib is never built at all and
sublib-config.cmake is not found.
I manually set the PATHS to sublib-config.cmake in find_package() but it still failed.
Could you please tell me how fix the EXPORT issue?
Thank you.
Best regards,
David Hu
You should not have to call find_package(sublib) in your top-level CMakeLists.txt, this is intended to be used by a project that uses sublib once it is installed. Because you call add_subdirectory(sublib) in your CMakeLists.txt, the target sublib is already available where you call target_link_directories(app sublib).
I tried to answer it by myself. I'm inspired by #piwi.
If the sublib is put under app as a sub-directory, sublib source code should be built together with those of app, rather than treating sublib as an standalone library. No need to export sublib.
Export and install of sublib is only necessary when sublib is placed as an independent library. Export and install the sublib in sublib CMakeLists.txt. Put a Findsublib.cmake under app's cmake/modules. Thus later when app CMakeLists.txt call find_package(sublib), Findsublib.cmake tells app how to find out sublib and build or link sublib
I have a simple project with one shared library called A and one executable called B linking A. I make a Visual Studio 2017 build just outside my sources so that the build directory and the source directory have both the same parent directory. This is fine.
But when I build my Visual Studio 2017 solution, many undesired directories appear under parent directory as well; one for each target that did run (A, B, INSTALL, etc.) that contains the build log for that target. I don't want those polluting log directories or it would be OK if they would appear under my build directory along Visual Studio 2017 stuff if they can't be avoided. Anyone knows how to handle this?
CMake version: 3.8.1
EDIT
The last 3 directories are those that are unwanted:
Parent directory
|-- build-vc15-x64 directory
|-- VS 2017 related stuff
|-- sources directory
|-- CMakeLists.txt
|-- libA sources directory
|-- stuff for libA
|-- execB sources directory
|-- stuff for execB
|-- unexpected directory here when building libA in solution in build-vc15-x64 (contains build log file of libA)
|-- unexpected directory here when building execB in solution in build-vc-15-x64 (contains build log file of execB)
|-- x64 (contains build log file of target INSTALL)
Use out-of-source builds, in other words, your build and your source directory should be different directories. Additionally, you have to call CMake and build just within your build directory, not in the parent directory. CMake creates a bunch of auxiliary files and directory right where it is called.
There is no point calling CMake in the common parent directory of source and build dir.
Let's say there's following directory structure:
root
|
+--projects
| |
| +-test
| |
| +-CMakeFiles.txt
|
+--libs
|
+-testlib
|
+-CMakeFiles.txt
test contains CMakeFiles.txt and testlib also contains CMakeFiles.txt. "test" produces an executable and "testlib" produces a static library.
I want "test" to link with "testlib" without using symlinks and without moving "testlib" library into a subdirectory within "test".
Because "testlib" isn't a subdirectory of "test", I can't do
add_subdirectory("../../libs/testlib")
In test's CMakeFiles.txt - CMake will complain about "testlib" not being in the "test" subdirectory.
Also, because system has several different compilers, I can't simply install "testlib" libraries into some kind of central directory, so I want test to compile a local copy of testlib and link with it (i.e. as if testlib was a subdirectory). I also want the "test" project to automatically rebuild "testlib" if it has been changed.
So, how can I deal with it? I am using CMake 2.8.4 on Windows XP SP3.
You could either provide a top-level CMakeLists.txt in root, or provide a binary directory to the add_subdirectory command; e.g.
add_subdirectory("../../libs/testlib" "${CMAKE_CURRENT_BINARY_DIR}/testlib_build")
This creates a subdirectory called testlib_build in your current build directory which contains the generated project files for testlib, but not the source.
For further info, run
cmake --help-command ADD_SUBDIRECTORY
The only way I see to do this - create CMakeLists.txt in root and put the following code there:
add_subdirectory(projects/test)
add_subdirectory(lib/testlib)
When you have done this, you can do target_link_libraries(test testlib) in test/CMakeLists.txt, and it will be automatically rebuilt if you change something in testlib.