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
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.
I configured wxWidgets in CMake and built it with MinGW-x64. After building binaries I used the command mingw32-make install (as used in OpenCV) and It was automatically installed with the file arrangement shown below.
C:\Program Files (x86)\wxWidgets
├───include
│ └───wx
│ ├───android
│ ├───aui
│ ├───dfb
│ ├───generic
│ ├───gtk
│ ├───gtk1
│ ├───html
│ ├───meta
│ ├───motif
│ ├───msw
│ ├───osx
| |...
└───lib
└───gcc_dll
└───mswu
└───wx
But after the installation, I provided the parameters Compiler and Linker at Code::Blocks-> Settings-> Compiler -> Search Directories , but it gave errors while compiling a sample program, indicating the non-standard procedure.
I don't know the next step to associate the libraries and include files with Code::Blocks correctly. I have already googled it and most web-results use makefile.gcc in procedure. How to use wxWidgets in CodeBlocks after that?
Be advised that CMake is not an official way to build wxWidgets. You can however build your own software using this tool. CMake incorporation is started fairy recently and will be available (fully tested) in version 3.2. (hopefully).
Now I don't know what error message(s) you received in C::B, but you have to select exactly the same options for the new project as the one you build wxWidgets with. I.e. if you supply SHARED=0 during wxWidgets compilation you absolutely have to select SHARED=0 in the C::B project. And so forth.
Without the exact error message that the best suggestion you will get.
Also, you didn't mention you version of wxWidgets. Please do so in the future, especially since you are working with the IDE that does not immediately utilize the latest version of wx.
HTH.
Because each project (you have created a project, right? C::B requires it) may need different libraries and options I prefer not to use "global" C::B settings (apart from 'Toolchain executables').
Instead go to Project-->Build options. Check that the 'Selected compiler` is the one you want.
the tab Compiler settings refers to your compiler (g++), not to wxWidgets requirements. Take a look at the flags. Other options like -mthreads may be required.
The tab Linker settings is good for all Windows .dll, such as kernel32, user32, winmm, and about a dozen more.
If you have different targets, such as "debug" and "release" then wxWidgets libs are different (the "debug" ones have a d near the end of each name). Thus you must add different wx libs for different targets. Select one target (big box at left) and again in the Linker settings tab add those libs (wxmsw31u_core, wxbase31u, etc, or just the "big monolitic" one if you built this instead of several files) Seems you only have a "release" target, select it.
To instruct the compiler & linker about where it can find these wxWidgets files (.dll or .a) and its headers use the Search directories tab. Again, different targets use different dirs.
The compiler searches for .h, in your case add the path C:\Program Files (x86)\wxWidgets\include and also C:\Program Files (x86)\wxWidgets\lib\gcc_dll\mswu
For the linker (in Linkersub-tab) add C:\Program Files (x86)\wxWidgets\lib\gcc_dll
The Resource compiler sub-tab, for your .res file (likely you use one) uses also some wxWidgets headers, so add the same C:\Program Files (x86)\wxWidgets\include
Don't forget that wxWidgets uses some definitions.
Go to tab Compiler settings sub-tab #defines and add entries: __GNUWIN32__ and __WXMSW__
For more options read yourwxdir\docs\msw\install.txt
I was struggling with using SDL2 and Qt Creator and found some threads here on SO that were mostly helpful but nothing that put it all together for SDL2 and Qt Creator on Windows 10. The main issue was that I could not use the console for I/O at the same time as SDL2 and following the other recommendations, a number of different things went wrong.
There were two keys:
Which SDL2.dll file to use and which directory to place it.
Some said use the SDL2.dll file download from the SDL website. Others said put this file in the main project directory, which did not work for me. What worked for me was first doing a build of my project (which failed) but creates a "build-..." directory. Then, taking the SDL2.dll file from installDir\SDL2-2.0.5\i686-w64-mingw32\bin and placing it in the "build-..." directory.
In the project.pro file, adding manually:
INCLUDEPATH += installDir/SDL2-2.0.5/i686-w64-mingw32/include
LIBS += -L installDir/SDL2-2.0.5/i686-w64-mingw32/lib -lmingw32 -mwindows -mconsole -lSDL2main -lSDL2
CXXFLAGS = -std=c++11
To be honest, I don't know if all of the calls in LIBS are needed, but it's now working perfectly for me and I thought I'd share some knowledge.
Where to put the DLL
The dll, is required to be in a directory which match one of the following rules:
Is part of the $PATH$ environment variable
Is in the same directory than the executable
Is in a directory which is actively specified in your code and loaded "manually".
In my case, I just moved those DLL to my /bin folder.
Libs and includes
Includes are required for the compiler, for this purpose, both of the following possibilities match:
Copy the SDL includes in the compiler include directory.
Add the include path to the project using INCLUDEPATH as explained by #launchpadmcquack.
Libs are required by the linker, for this purpose, both of the following possibilities match:
Copy the SDL libs in the compiler lib directory.
Add the lib to the project using LIBS as explained in the question.
Considering the library list, SDL2 is required, others depends on you specific projects. E.g. In my case I do not link any of the mingw32, mwindows or mconsole.
Additional note: You may specify C++11 with the CONFIG parameter:
CONFIG *= c++11
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.
My main aim is to get the GSL Shell working on my OSX 10.7 system. So far I have the correct version of lua with the correct patches running. I also have a working version of GSL which compiles and runs example programs. I can build agg perfectly and also run their example programs by running make in the macosx_sdl folder.
My first question is how on earth do I create my own project with agg? I know that you are supposed to simply add the files to your project file and go, but this does not seem to want to compile for me. Is it simply a case of adding the include directory and the libagg.a?
Finally, how do I build gsl shell? Currently it complains about the agg-plot folder a lot, so where do I put the agg files to make this build, then when i've done it where do I place the agg files so that the lua scripts can get to them?!
Hope someone can help!
In general to use the AGG library you need to make sure that the compiler is able to find the headers files and, during the linking, the libraries, either in form of a static or dynamic libraries.
To make the headers files and the libraries available you need to take into account the system that is used to build the software. If a traditional makefile sistem is used you need to add some flags to make sure that the headers file can be found. This can be achieved by adding into the makefile something like:
CFLAGS += -I/path/to/agg/headers
and for the linker:
LIBS += -L/path/to/agg/library -lagg -lm
In the specific case of GSL Shell 1.1 the file "make-packages" is used in the Makefile to configure the required packages. You can add here the flags required to locate the AGG library:
AGG_INCLUDES = -I/usr/include/agg2
AGG_LIBS = -lagg -lX11 -lpthread -lsupc++
you should just modify the path provided with the "-I" option and, in AGG_LIBS, add an option "-L/path/to/agg/library" to specify the path where the AGG libraries are located.
Please note also that the agg libraries depends on other libraries. For example on linux it needs at least the X11 library. The libraries supc++ may be needed if the linking is made by invoking gcc instead of g++ because if gcc is used the C++ runtime libraries are not included.