I am new to llvm, am trying to write a pass for llvm Hello
I have downloaded and built llvm in linux machine by following the link http://llvm.org/docs/GettingStarted.html
I have tried to write a pass by following the link http://llvm.org/docs/WritingAnLLVMPass.html
I have copied the makefile specified in the link to the Hello folder in llvm and tried to perform a make. But I encounter the below error.
Makefile:14: ../../../Makefile.common: No such file or directory
make: *** No rule to make target `../../../Makefile.common'. Stop.
I understand that it is not able to find the Makefile.common. But most of the stuff in llvm is readonly and downloaded from the svn repository.
Can anyone assist me with this issue? Am I missing anything, am I following the correct way?
Is there any better tutorial anyone can refer?
TIA
LLVM now builds with CMake, so that old Makefile won't work. The same tutorial you linked points out how to write the CMakeLists.txt.
Out-of-tree build
Set up a directory structure like this:
HelloPassProject
├── build
├── CMakeLists.txt
└── HelloPass
├── CMakeLists.txt
└── HelloPass.cpp
So there's a top-level HelloPassProject, which contains the root CMakeLists.txt, a build directory where we'll build our pass and a HelloPass directory containing the actual pass source and the pass CMakeLists.txt.
Contents of HelloPassProject/CMakeLists.txt:
find_package(LLVM REQUIRED CONFIG)
list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_DIR}")
include(AddLLVM)
add_definitions(${LLVM_DEFINITIONS})
include_directories(${LLVM_INCLUDE_DIRS})
add_subdirectory(HelloPass)
Contents of HelloPassProject/HelloPass/CMakeLists.txt (list your sources here):
add_llvm_loadable_module(LLVMHelloPass HelloPass.cpp)
To build against an installed LLVM:
cd HelloPassProject/build
cmake ..
make
To build against an LLVM you've built from source (let's say it's been built in ~/llvm-project/build):
cd HelloPassProject/build
cmake -DCMAKE_PREFIX_PATH=~/llvm-project/build ..
make
In-tree build
You just need the HelloPass subdirectory from the out-of-tree build. Copy that inside <LLVM root>/lib/Transform. Add a add_subdirectory(HelloPass) line to <LLVM root>/lib/Transform/CMakeLists.txt. Build LLVM as usual.
There is a Makefile.common under llvm.3.9.0-src, i.e. your llvm source root. So that should not be your problem.
Note that there are some make variables to set in Makefile.common.
Related
I have a C file containing a function my_library_function() that I have compiled into a static library using gcc and packaged into an xcframework called mylib.xcframework using xcodebuild -create-framework. I have added this framework to an Xcode project for a Mac App. However within my Mac App I am unable to call this function, and am generally unsure about how to do so. I have tried import mylib from within Swift files and tried to directly call the function my_library_function() but in both cases have gotten compiler errors No such module mylib and Use of unresolved identifier 'my_library_function'. The only workaround I have found is to create a bridging header and #include the header file from its path within the xcframework. However, since eventually I would like to work with a more complex library and cross compile and have the xcframework include static libraries for multiple targets this seems like a hacky workaround. Is there some way I can do this without the bridging headers, am I missing something in this process?
Below are exact instructions of exactly what I did.
First I compiled the C code into a static library. The source code for the library contains a single function:
#include <stdio.h>
void my_library_function(void) {
printf("called from a static library");
}
mylib.c
I also have a header for the above:
void my_library_function(void);
mylib.h
The tree for the source code is as follows:
.
├── include
│ └── mylib.h
└── mylib.c
Project source tree
I then compiled the C code into a static library using:
> gcc -c mylib.c -o mylib.o
> ar rcs mylib.a mylib.o
Then I created an xcframework with:
xcodebuild -create-xcframework -library mylib.a -headers include -output mylib.xcframework
This resulted in an xcframework as so:
.
├── Info.plist
└── macos-x86_64
├── Headers
│ └── mylib.h
└── mylib.a
mylib.xcframework source tree
I then created a new Xcode project using Xcode 11.
At the root of the project I created a new group and called it Frameworks. I then dragged and dropped the xcframework into XCode frameworks group and checked the copy items if needed checkbox and the create groups radio button.
In the Xcode projects general tab, under Frameworks, Libraries and Embedded Content I set the framework to Embed & Sign.
Under the Build Settings tab, under Signing, I set Other Code Signing Flags to --deep to prevent a codesign error. In the same Build Settings tab, under Linking, the Runpath Search Paths is set to #executable_path/../Frameworks/. Additionally in the Build Settings tab under Search Paths, I have tried to set the Framework Search Paths, Library Search Paths and Header Search Paths to this same value #executable_path/../Frameworks/ and I have also tried with these paths as empty.
Unfortunately I am not able to use the my_library_function() from anywhere in the application, nor am I able to import mylib from Swift.
The only workaround I have found is to create an objective C bridging header and make a #include explicitly point within the framework folder into the Headers/mylib.h to be able to call my function. This seems like a hacky solution though as eventually I would like to cross compile my code and will have separate header files for each separate library for different architectures and it might get quite complex to do it this way. Is there something I am missing as to how to include my function from within an XCFramework with a MacOS Swift project?
Below are some images of my Xcode configuration:
I built with clang instead of gcc and included a clang modulemap file alongside the header. It now builds and even offers Xcode autocompletion.
so I'm learning about llvm and I decided to build the 3.8 from the tars that I downloaded from LLVM site.
Everything works fine and I managed to build the sources in a separate build folder.
(After downloading all the sources)
$cd llvm3.8/build
$cmake -G "Unix Makefiles" ../llvm
$make -j 4
$make install
so my dir looks a bit like this:
llvm3.8/
llvm3.8/build
llvm3.8/llvm
While learning how to write a LLVM pass I noticed that my build folder is missing these files:
Makefile.config
Makefile.common
Makefile.rule
that I use in the Makefile I have written for the pass I've implemented.
What I know is that the source has these files:
$cd llvm3.8/llvm
$ls:
CMakeLists.txt README.txt llvm.spec.in
CODE_OWNERS.TXT autoconf projects
CREDITS.TXT bindings resources
LICENSE.TXT cmake test
LLVMBuild.txt configure tools
Makefile docs unittests
Makefile.common examples utils
Makefile.config.in include
Makefile.rules lib
while my build folder doesn't.
$ cd llvm3.8/build
$ ls
CMakeCache.txt cmake libexec
CMakeFiles cmake_install.cmake projects
CPackConfig.cmake compile_commands.json share
CPackSourceConfig.cmake docs test
DummyConfigureOutput examples tools
LLVMBuild.cmake include unittests
Makefile install_manifest.txt utils
bin lib
Is my build folder containing what it is supposed to contain?
Maybe the pass must be written in the sources llvm3.8/llvm?
Thanks for the help.
You are suppose to write your pass in llvm/lib/Transforms/YourPassName
Create a directory in build:
mkdir -p llvm3.8/build/lib/Transforms/YourPassName
I would recommend you to use cmake. As autoconf is going to be deprecated in llvm3.9. For it:
Add entry in llvm/lib/Transforms/CMakeLists.txt
add_subdirectory(YourPassName)
After putting the entry, create CMakeLists.Txt in llvm/lib/Transforms/YourPassName like the other llvm passes.
Now use
cmake ../llvm3.8
From inside the pass directory:
make
Also if you have install llvm and want to do standalone, use the approach given in this answer: https://stackoverflow.com/a/37308946/4946286
I am trying to instal aquila lib using link this. But when i write "mingw32-make", it gives the following error.
Mingw32-make: *** No targets specified and no makefile found. Stop.
What could be the issue?
The way I installed this library was by using CMake (https://cmake.org/download/) as it specifies it as a requisite on the Aquila Website (http://aquila-dsp.org/download/).
The default CXX and C compiler on the CMakeLists.txt are not MinGW32. So, in order to change this just open up the CMake GUI which will be in the bin folder of wherever you installed it.
Then click "Browse Source" and choose the directory where the CMakeLists.txt file is. Last thing is to create a new folder in that same directory because that will force CMake to let you specify the type of Makefile it will generate. Then, of course, you choose to build the Makefile in the new folder you just made, and when you hit configure you will choose MinGW Makefile in the dropdown list...configure...generate...mingw32-make the Makefile in the build folder.
I'm cross compiling using Qmake and QtCreator. In the settings for the Kits (toolchain and qmake details are set there) there is a field called Sysroot:.
(Example here)
Since QtCreator and Qmake are, at the end, responsible for generating a Makefile, my question is, to what does that option translate to in the Makefile and how does it get passed to the toolchain?
Motivation for the question
I have the Sysroot: pointing to ~/path-to-sysroot. ~/path-to-sysroot contains the regular sysroot structure cross compiled for an embedded target.
~/path-to-sysroot
├── bin
├── include
├── lib
├── sbin
├── share
└── usr
When I try to cross compile some code which depends on the libraries in ~/path-to-sysroot/usr/lib, it fails with a message that the libs are missing, but the exist there. I have parsed the generated makefile and found no traces of ~/path-to-sysroot/usr/lib.
from :http://doc.qt.io/qt-5/qt-conf.html
The qt.conf file can be used to override the hard-coded paths that are compiled into the Qt library. These paths are accessible using the QLibraryInfo class. Without qt.conf, the functions in QLibraryInfo return these hard-coded paths; otherwise they return the paths as specified in qt.conf.
Without qt.conf, the Qt libraries will use the hard-coded paths to look for plugins, translations, and so on. These paths may not exist on the target system, or they may not be accessible. Because of this, you may need qt.conf to make the Qt libraries look elsewhere.
qmake -query
QT_SYSROOT:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux
QT_INSTALL_PREFIX:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr
QT_INSTALL_PREFIX/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr
QT_INSTALL_ARCHDATA:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5
QT_INSTALL_ARCHDATA/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5
QT_INSTALL_DATA:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5
QT_INSTALL_DATA/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5
QT_INSTALL_DOCS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/doc/qt5
QT_INSTALL_DOCS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/doc/qt5
QT_INSTALL_HEADERS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/include/qt5
QT_INSTALL_HEADERS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/include/qt5
QT_INSTALL_LIBS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib
QT_INSTALL_LIBS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib
QT_INSTALL_LIBEXECS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/libexec
QT_INSTALL_LIBEXECS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/libexec
QT_INSTALL_BINS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/bin/qt5
QT_INSTALL_BINS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/bin/qt5
QT_INSTALL_TESTS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/tests
QT_INSTALL_TESTS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/tests
QT_INSTALL_PLUGINS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/plugins
QT_INSTALL_PLUGINS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/plugins
QT_INSTALL_IMPORTS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/imports
QT_INSTALL_IMPORTS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/imports
QT_INSTALL_QML:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/qml
QT_INSTALL_QML/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/qml
QT_INSTALL_TRANSLATIONS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/translations
QT_INSTALL_TRANSLATIONS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/translations
QT_INSTALL_CONFIGURATION:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/etc/qt5
QT_INSTALL_CONFIGURATION/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/etc/qt5
QT_INSTALL_EXAMPLES:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_INSTALL_EXAMPLES/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_INSTALL_DEMOS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_INSTALL_DEMOS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_HOST_PREFIX:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr
QT_HOST_DATA:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5
QT_HOST_BINS:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/bin/qt5
QT_HOST_LIBS:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib
QT_EXTERNAL_HOST_BINS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/usr/bin/qt5
QMAKE_SPEC:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/usr/lib/qt5/mkspecs/linux-oe-g++
QMAKE_XSPEC:linux-oe-g++
QMAKE_VERSION:3.0
QT_VERSION:5.4.1
qmake doesnot uses a sysroot argument it has all the paths in it. You can customize qmake by overriding those paths in qt.conf but still it has no path which shows sysroot. And I don't think it has any option to specify sysroot. You have to manually set the sysroot in Compiler flags in qtcreator
I'm trying to use cmake (on Linux with GNU make and g++) to build a project with two sub-directories: MyLib and MyApp. MyLib contains source for a static library; MyApp needs to link against that library. I'm trying to build on Linux with generated makefiles using the following CMakeLists.txt:
cmake_minimum_required (VERSION 2.6)
project (MyProj)
include_directories (MyLib)
file(GLOB MyLibSrc MyLib/*.cpp)
add_library(MyLibrary STATIC ${MyLibSrc})
file(GLOB MyAppSrc MyApp/*.cpp)
add_executable(MyApplication ${MyAppSrc})
target_link_libraries(MyApplication MyLibrary)
This 'almost' works. It fails at link time because while it generates libMyLibrary.a - it is in the root. When I add:
link_directories(${MyProj_BINARY_DIR})
it makes no difference.
I've got a few (inter-linked) questions:
What's the best way to coerce cmake into building my library and executable into a 'staging directory' — say MyStage — to keep targets separate from source?
How do I convince cmake to link the application against the library?
If I wanted to build a debug and a release version, what's the best way to extend my cmake scripts to do this — making sure that the debug application links against the debug library and the release application against the release library?
I'm a relative newcomer to cmake. I've read what I can find on the web, but find myself struggling to get my library to link with my executable. This sort of a configuration, to my mind, should be quite common. An example from which to crib would be very helpful, but I've not found one.
Well, it is better to read this example and do exactly as suggested.
cmake_minimum_required (VERSION 2.6)
project (MyProj CXX)
add_subdirectory(MyLib)
add_subdirectory(MyApp)
Then for each subdirectory specified, CMakeLists.txt files are created
MyLib\CMakeLists.txt
file(GLOB SRC_FILES *.cpp)
add_library(MyLib ${SRC_FILES})
MyApp\CMakeLists.txt
file(GLOB SRC_FILES *.cpp)
add_executable(MyApp ${SRC_FILES})
target_link_libraries(MyApp MyLib)
Use "out of the source build". Make a directory used only for build and while in it, call
cmake <path to the sources, it may be relative>
Either use
link_directories(${MyProj_BINARY_DIR}/MyLib)
or make CMakeLists.txt in each subdirectory - that would be better for project larger than very small.
This is a bit tricky, check out CMAKE_BUILD_TYPE in the docs (you can set it and/or "if" by it). You can also set it from command line:
cmake -DCMAKE_BUILD_TYPE=Debug
I've discovered the 'optimal' solution to (1)... so, thought I should post it here:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY MyStage)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY MyStage)
The thing that confused me previously is that static libraries are not considered a LIBRARY by Cmake - they're considered to be ARCHIVEs.
Do not add libraries and executables in the root Cmakelists.txt. Add these libraries and executables in Cmakelists.txt of subdirectories.