i'm trying to create an LLVM pass using the guide at http://llvm.org/releases/2.9/docs/WritingAnLLVMPass.html
but i'm having several problems:
i haven't many of the folder that are indicated into the guide (lib/Transform/Hello) and (Debug+Asserts), i have created them, is it right? what's the right path?
i create these: /usr/lib/llvm-2.9/lib/Transforms/Hello and /usr/lib/llvm-2.9/Debug+Asserts
when i try to make the file in the guide i have error:
.
# Makefile for hello pass
# Path to top level of LLVM heirarchy
LEVEL = /usr/lib/llvm-2.9/build #*********I MODIFY THIS!!!! ***************
# Name of the library to build
LIBRARYNAME = Hello
# Make the shared library become a loadable module so the tools can
# dlopen/dlsym on the resulting library.
LOADABLE_MODULE = 1
# Tell the build system which LLVM libraries your pass needs. You'll probably
# need at least LLVMSystem.a, LLVMSupport.a, LLVMCore.a but possibly several
# others too.
LLVMLIBS = LLVMCore.a LLVMSupport.a LLVMSystem.a
# Include the makefile implementation stuff
include $(LEVEL)/Makefile.common
and i modify also other lines into Makefile.common:
ifndef LLVM_SRC_ROOT
include $(LEVEL)/Makefile.rules
else
include $(LLVM_SRC_ROOT)/Makefile.rules
endif
because it doesn't find the Makefile.rules (in this way it works)
but now i have this error when i do make into the folder containing my hello.c file (/usr/lib/llvm-2.9/lib/Transforms/Hello):
make: *** No rule to make target "/configure", needed by "/config.status". Stop.
what's the problem?!?
Apparently, it seems you're trying to develop using the binary of the libraries. Unfortunately, this won't work. You need to download sources, build them and then start developing your own pass.
Also, 2.9 is already too ancient. Consider at least upgrading to 3.0 release.
Related
I'm trying to have my recipe be compiled and linked against the arm libraries. I'm using cmake. I can't seem to figure out the right work flow, after having read trough multiple documents on the yocto site and reference materials. My approach right now is:
Set the source
Build my target minal image, without the layer that I want to use
Try to build my specific recipe: bitbake Test
I have downloaded the arm toolchain from the Yocto site, and prepared it in my sources/poky. Here I can see the systroots and all the libraries that I would need. My recipe bb file is the following:
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#
SUMMARY = "Project"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://."
S = "${WORKDIR}/project/src"
inherit pkgconfig cmake externalsrc
And my CMake file contains, among more:
link_directories(/media/traffic/Yocto/QorIQ-SDK-V2.0-20160527-yocto/sources/poky/sysroots/aarch64-poky-linux/usr/lib)
I'm able to compile a hello world project fine, but as soon as external libraries take a role, it goes wrong.
cannot find /usr/lib/libpthread_nonshared.a
/media/traffic/Yocto/QorIQ-SDK-V2.0-20160527-yocto/build_ls2084abluebox/tmp/sysroots/x86_64-linux/usr/bin/aarch64-fsl-linux/../../libexec/aarch64-fsl-linux/gcc/aarch64-fsl-linux/4.9.3/ld: cannot find /usr/lib/libpthread_nonshared.a
It seems to look in the wrong folder. Are the steps that I'm taking correctly? Or am i missing something?
Elmar
Which poky version are you using? I got exactly the same issue recently with another package. There are 2 issues here:
It cannot find the pThread library. I added a FindThreads.cmake in the tree and imported it. But then the linker could not make it. I went to the conclusion, cmake itself had an issue with this library and ended changing the poky commit to have a different version of CMake. Note that you can also keep the new poky versions and have the custom CMake in your layer.
CMake 3.7 and 3.8.2 were not working properly but the 3.7.1 was for me (hash c9a512b6408d4cc11c1b36f7bc1b9b1c31056ce1). To find out which commit, you can execute
git log --pretty=oneline | grep cmake:
While reading through the documentation for Qt 5.1, and specifically qmake, I was stumped by the explanation given in the documentation for the qmake CONFIG() function. I completely understood the one-argument version of the function, but the two-argument version makes absolutely no sense to me. I think my confusion is coming from the lack of a definition for 'active config' since the Qt 5.1 documentation says the following:
This function can be used to test for variables placed into the CONFIG variable. This is the same as scopes, but has the added advantage that a second parameter can be passed to test for the active config. As the order of values is important in CONFIG variables (that is, the last one set will be considered the active config for mutually exclusive values) a second parameter can be used to specify a set of values to consider.
I would greatly appreciate an explanation for this concept of 'active config' as I am completely stumped and cannot make any practical sense out of this second argument.
The CONFIG variable can contain conflicting options, such as both "release" and "debug". If CONFIG contains both "release" and "debug" at the same time then either "release" or "debug" is effective. The interpretation of conflicting options in CONFIG depends on the order: the last one set will be considered the effective or active config.
Using CONFIG() with one parameter tells you whether an option is present or not in CONFIG variable. If both "release" and "debug" are present then both CONFIG(release) and CONFIG(debug) returns true.
Using CONFIG() with two parameters tells you whether an option is effective or not, is it the active config or not. CONFIG(debug, debug|release) tests whether "debug" is the last (and hence, active) among the "debug" and "release" options.
See this question and answer as well.
EDIT:
I've created a new project with Qt Creator, opened the .pro file generated and added the following line at the bottom: message($${CONFIG}) so that we can see the contents of CONFIG when qmake is run. I show you the whole .pro file:
QT += core
QT -= gui
TARGET = QMakeConfigTest
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp
message($${CONFIG})
There are two lines where CONFIG is modified, only one option is added and one is removed. Then I've chosen Release Build and run qmake. This is what I see in Compile Output window:
08:53:49: Running steps for project QMakeConfigTest...
08:53:49: Starting: "C:\Qt\Qt5.0.2\5.0.2\msvc2010\bin\qmake.exe"
C:\QMakeConfigTest\QMakeConfigTest.pro -r -spec win32-msvc2010
Project MESSAGE: lex yacc debug exceptions depend_includepath
testcase_targets import_plugins import_qpa_plugin rtti_off
incremental_off windows qt warn_on release link_prl incremental flat
precompile_header autogen_precompile_source debug_and_release
debug_and_release_target embed_manifest_dll embed_manifest_exe
copy_dir_files release shared rtti qpa win32 msvc debug DebugBuild
Debug build_pass console
08:53:49: The process "C:\Qt\Qt5.0.2\5.0.2\msvc2010\bin\qmake.exe"
exited normally.
08:53:49: Elapsed time: 00:00.
As you can see the CONFIG variable contains a lot of default options beside the console option added in the .pro file. It contains both debug and release twice and debug_and_release once.
Where are these default options coming from? They are defined in .prf and .conf files that are loaded from a directory called mkspecs. So the answer to the question you asked in your comment is that before a .pro file is processed by qmake several other files are pre-processed based on your compiler and platform. These files can add the same options more than once and can add conflicting options to the CONFIG variable.
Here is the contents of C:\Qt\Qt5.0.2\5.0.2\msvc2010\mkspecs\features\default_pre.prf:
# This file is loaded by qmake right before each actual project file.
# Note that evaluating variable assignments from the command line
# still happens in between these two steps.
load(exclusive_builds)
CONFIG = \
lex yacc debug exceptions depend_includepath \
testcase_targets import_plugins import_qpa_plugin \
$$CONFIG
As you can see the first 8 default options are defined in this file.
The contents of C:\Qt\Qt5.0.2\5.0.2\msvc2010\mkspecs\features\win32\default_pre.prf:
CONFIG = rtti_off incremental_off windows $$CONFIG
load(default_pre)
The relevant part of C:\Qt\Qt5.0.2\5.0.2\msvc2010\mkspecs\features\spec_pre.prf:
# This file is loaded by qmake right before loading the qmakespec.
# At this point, the built-in variables have been set up and the project's
# .qmake.super was read (if present).
CONFIG = qt warn_on release link_prl
QT = core gui
Qt Creator runs qmake.exe with the following option: -spec win32-msvc2010. Let's see the qmake manual about the -spec option:
-spec spec: qmake will use spec as a path to platform and compiler information,
and the value of QMAKESPEC will be ignored.
The first few lines from C:\Qt\Qt5.0.2\5.0.2\msvc2010\mkspecs\win32-msvc2010\qmake.conf:
#
# qmake configuration for win32-msvc2010
#
# Written for Microsoft Visual C++ 2010
#
MAKEFILE_GENERATOR = MSBUILD
QMAKE_PLATFORM = win32
CONFIG += incremental flat precompile_header autogen_precompile_source debug_and_release debug_and_release_target embed_manifest_dll embed_manifest_exe
DEFINES += UNICODE WIN32
QMAKE_COMPILER_DEFINES += _MSC_VER=1600 WIN32
gcc (GCC) 4.7.2
cmake version 2.8.11
Hello,
I wondering if there is a way around the following issue. I have highlighted below:
SET(GW_SOURCE_FILES
module.c
module_imp.c
module_message.c
module_config.c
module_queue.c)
# Compiles the source files to create the shared library called dlg_gw.so
ADD_LIBRARY(dlg_gw SHARED ${GW_SOURCE_FILES})
# Link additional libraries to this
TARGET_LINK_LIBRARIES(dlg_gw gc srl ${APRUTIL})
# ISSUE: Now I want to create my executable using the same source files. module.c is where my 'void main(void)' is.
# However, I have some functions in there which will also be part of the library.
# However, this will recompile the same source files all over again. I don't really like that behaviour.
ADD_EXECUTABLE(sun_gw ${GW_SOURCE_FILES})
# After the executable is created, link the libraries with it.
TARGET_LINK_LIBRARIES(sun_gw ${APR} driver dlg_gw dlg_sip dlg_ss7 dlg_isdn)
I hope you can see the issue above, as I am compiling the same source files twice. Once to create the dlg_gw library. Then again to create the executable sun_gw.
I was thinking of taking out the 'void main(void)' and putting it in a new file called runtime.c and then doing the following:
ADD_EXECUTABLE(sun_gw runtime.c)
But the above require me to change some of the source code.
Many thanks for any other suggestions,
The "OBJECT" library type introduced in CMake 2.8.8 can be used to avoid repetitive build of same files.
See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
I'm trying to make a small game using both SFML and Box2D. I have the following directory structure:
/
src/
game/ # my code
thirdparty/ # other libraries' code
box2d/
sfml/
bin/
etc...
I'm trying to set it up so that I can run make and have box2d or sfml compile as well if they need, since I might make some changes to the libraries.
I've tried putting this in my CMkaeLists.txt:
find_package(Box2D)
find_package(sfml-window)
find_package(sfml-graphics)
find_package(sfml-system)
as well as other things, but I keep getting errors and I'm not sure how to get around them. for example:
CMake Error at CMakeLists.txt:20 (find_package):
Could not find module Findsfml-window.cmake or a configuration file for
package sfml-window.
Adjust CMAKE_MODULE_PATH to find Findsfml-window.cmake or set
sfml-window_DIR to the directory containing a CMake configuration file for
sfml-window. The file will have one of the following names:
sfml-windowConfig.cmake
sfml-window-config.cmake
But I can't find any of the files it lists there.
The find_pacakge command is for finding packages that are defined in for cmake as modules or configurations. There is probably not a cmake module or config defined for these libraries. So, if you want to use the find package command to find these libraries then you will need to create a cmake module that knows how to find them. Given your stated requirements I would not think that this is easiest way to do it.
If you are statically linking you libraries then set up a custom target to invoke make on each of the libraries. Add the include directories to your include path. Use find_library command to find the libraries.
If you intend to dynamically link your libraries then create a custom target to build and install your libraries and you should be good as long as you install them in one of the normal places.
Have a gander here:
http://www.itk.org/Wiki/CMake:How_To_Find_Libraries Writing find modules
Take a look at the "Writing find modules" section. Be sure to read the document all the way through.
If you want to make redistributable and portable cmake projects, I think this is the right direction for you to go.
I have created a simple application that works ok. However, now I need to link with some libraries in the following directory.
/opt/norton/lib
In my make file I have the following with works, but I need to use cmake
LIBS_PATH = -L/opt/norton/lib
INC_PATH = -I/opt/norton/inc
LIBS = -lntctrl
In my CMakeList.txt I have this but doesn't work I keep gettng the following error:
undefined reference to `nt_init'
This is my CMakeList.txt
# Includes files
INCLUDE_DIRECTORIES(/opt/norton/inc)
# Link libraries
LINK_DIRECTORIES(/opt/norton/lib)
# Add the library that is used by nt_init
TARGET_LINK_LIBRARIES(-lntctrl)
ADD_LIBRARY(application initialize_nw)
Many thanks for any advice,
Try out TARGET_LINK_LIBRARIES(ntctrl), the -l flag should not be used there (guess from what I have in mind)
This is how I would write the cmake file:
include_directories(/opt/norton/inc)
link_directories(/opt/norton/lib)
add_executable(application initialize_nw)
target_link_libraries(application ntctrl)
To show what are the actual command lines run during a make, use:
make VERBOSE=1
Maybe this shows you the difference between what you ran manually and the cmake generated commands.