I want to cross compile a project from my linux machine to a raspberry pi using Qt creator. Now I have set up a kit with compilers (that I tested to work) and a sysroot. However when I try to compile a simple "Hello world" example in Qt creator I get an error:
#include <iostream>
using namespace std;
int main()
{
cout << "Hallo!!!" << endl;
return 0;
}
/usr/include/c++/5/iostream:38: from /usr/include/c++/5/iostream:38,
~/sysroot/usr/include/features.h:364: error: sys/cdefs.h: No such file or directory
I see that Qt tries to use uses the following file for compilation:
/usr/include/c++/5/iostream
However it should use ~/sysroot/usr/include/c++/6/iostream
In the kit I use I have specified ~/sysroot as the sysroot, but it seems to use the other c++ includes. How can I change this?
EDIT: I have found a solution for the problem. See answers below. However I'm not sure if this is the best solution. I there are better ways, please let me know.
I found the problem. The default qmake build step adds the argument " -spec linux-g++" to the call to qmake. However this causes the wrong compiler to be chosen. Since I cannot remove the argument from the qmake build step, I removed the qmake step and added a custom build step which calls qmake and omits the -spec argument. This seems to work, but it feels a little dirty. Maybe there are better/cleaner solutions for this?
I included <ncurses.h> , but can't link ncurses's libs in .pro file. I'm trying like this:
LIBS += -L"/usr/lib/" -libncurses.a
I tried different variations of linking (with/without file_type, different variations of directory), but it didn't help. Then I decided to link via console using:
g++ -lncurses main.cpp snake.cpp
Tried to put -lncurses in different places of command.
It gives me an error:
undefined reference to move(); (ncurses's func)
And it doesn't want to compile C++11 features, like std::list.empalce_front();. The reason I'm asking for help for second problem in the same question, is that if would able compile only via console, so i won't be able to use C++11 features, but i want to!
P.S. Of course, the main problem is with linking ncurses's libs
http://www.lucidarme.me/?p=3961 Here You can find a solution. Main reason is You incorrectly set project:
LIBS += -lncurses
Check a link I sent You. Everything is there clear.
I am using Qt and I am trying to use Botan. Everything seemed to go well, but when I go:
Botan::BigInt myInt;
In my constructor it works fine, but on the other hand if I go:
Botan::AutoSeeded_RNG rng;
It throws undefined errors:
C:\Users\Stevie\Desktop\asfsdf-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\debug\mainwindow.o:-1: In function `AutoSeeded_RNG':
C:\Users\Stevie\Desktop\asfsdf-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\..\..\..\botan\include\botan\auto_rng.h:40: error: undefined reference to `_imp___ZN5Botan23Global_State_Management12global_stateEv'
C:\Users\Stevie\Desktop\asfsdf-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\..\..\..\botan\include\botan\auto_rng.h:40: error: undefined reference to `_imp___ZN5Botan13Library_State10global_rngEv'
:-1: error: collect2: ld returned 1 exit status
I have no idea why it would work with a BigInt but not the AutoSeeded_RNG, but here are my exact steps:
Compiled the Botan source included in the Qt Creator source at "src/libs/3rdparty/botan/"
I installed Botan using the Windows Installer (1.10) from their website.
I took the libBotan.a, libBotand.a, botan.dll, and Botand.dll and put them in the location where I installed Botan (C:\botan). I overwrote any of those files that already existed.
I then created a new Qt project, and inside of the .pro file I added the following lines:
INCLUDEPATH += "C:/botan/include"
LIBS += "C:/botan/libBotan.a"
Next, I go into my "mainwindow.cpp", and add:
#include <botan/botan.h>
Everything compiles up to here successfully.
I now add this to my constructor:
Botan::AutoSeeded_RNG rng;
Now the above errors are thrown, and cannot be ran. If I replace the "AutoSeeded_RNG" with "BigInt", then it compiles perfectly.
Thanks for any help, Hetelek.
The statement to link against the Botan library looks strange to me. Normally, you specify library directories using the -L switch and add a library with the -l switch, i.e you should use
LIBS += -L"C:\botan" -lBotan
Note that the prefix and suffix of the library are not specified in lbotan. The linker will automatically look for a libbotan.a or botan.dll, depending on your environment.
Botan is also part of QtCreator. Maybe you should have a look at their repository. You can find .pri and .pro files there and probably only need to copy them. They also have written a .qbs driver for the new Qt build system.
Edit: I just compiled Botan from the QtCreator sources, as you also mentioned in your post. I then copied all the generated libraries in my own directory and I also used the botan.h which was shipped with QtCreator. On Linux I had to add
LIBS += -L"/dir/into/which/i/copied/botan/dlls" -LBotan -ldl
to the qmake .pro file. Note the additional -ldl otherwise I got undefined references to dlym, dlerror etc. I could compile a simple example with Botan::AutoSeeded_RNG without problems.
When I try to use gcc 4.6.2 with my qt I'm getting following error:
'g++-dw2' is not recognized as an internal or external command.
In Qt's pro file I have added:
QMAKE_CXXFLAGS += -std=c++0x
QMAKE_CXX = g++-dw2
QMAKE_LINK = g++-dw2
If I don't add those two lines I'm getting error: undefined reference to _unwindSomething
Does anyone knows how to solve it?
To solve the problem at hand:
If g++-dw2 is not already on your system, then you need to install it. Then you need to add it to your path or at least tell Qt the full path to the executable.
I am trying to port a fairly large C++ project to using g++ 4.0 on Mac OS X. My project compiles without errors, but I can't get GDB to work properly. When I look at the stack by typing "bt" on the GDB command line, all file names and line numbers displayed are wrong.
For example, according to the GDB stack trace, my main() function is supposed to be in stdexcept from the Mac OS X SDK, which does not make any sense.
What could cause GDB to malfunction so badly? I've already checked for #line and #file statements in my code and made sure that the code only has unix line endings. I've also cleaned and rebuilt the project. I've also tried debugging a Hello World project and that one did not have the same problem.
Could the problem have to do with one of the third party libraries I am linking and the way those are compiled? Or is it something completely different?
Here are two exemplary calls to gcc and ld as executed by Xcode. AFAIK all cpp-files in my project are compiled and linked with the same parameters.
/Developer/usr/bin/gcc-4.0 -x c++
-arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -fpermissive -Wreturn-type -Wunused-variable -DNO_BASS_SOUND -D_DEBUG -DXCODE -D__WXMAC__ -isysroot /Developer/SDKs/MacOSX10.5.sdk
-mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.4 -gdwarf-2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -c "/Users/adriangrigore/Documents/Gemsweeper
Mac/TSDLGameBase.cpp" -o
"/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Gemsweeper
Mac.build/Debug/Gemsweeper
Mac.build/Objects-normal/i386/TSDLGameBase.o"
/Developer/usr/bin/g++-4.0 -arch i386
-isysroot /Developer/SDKs/MacOSX10.5.sdk
"-L/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Debug"
-L/Developer/SDKs/MacOSX10.5.sdk/usr/local/lib
-L/opt/local/lib "-F/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Debug"
-F/Users/adriangrigore/Library/Frameworks
-F/Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks
-filelist "/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Gemsweeper
Mac.build/Debug/Gemsweeper
Mac.build/Objects-normal/i386/Gemsweeper
Mac.LinkFileList"
-mmacosx-version-min=10.4 /opt/local/lib/libboost_program_options-mt.a
/opt/local/lib/libboost_filesystem-mt.a
/opt/local/lib/libboost_serialization-mt.a
/opt/local/lib/libboost_system-mt.a
/opt/local/lib/libboost_thread-mt.a
"/Users/adriangrigore/Documents/Gemsweeper
Mac/3rd
party/FreeImage/Dist/libfreeimage.a"
"/Users/adriangrigore/Documents/Gemsweeper
Mac/3rd
party/cpuinfo-1.0/libcpuinfo.a"
-L/usr/local/lib -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL -lwx_macd_richtext-2.8 -lwx_macd_aui-2.8 -lwx_macd_xrc-2.8 -lwx_macd_qa-2.8 -lwx_macd_html-2.8 -lwx_macd_adv-2.8 -lwx_macd_core-2.8 -lwx_base_carbond_xml-2.8 -lwx_base_carbond_net-2.8 -lwx_base_carbond-2.8 -framework SDL -framework Cocoa -o "/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Debug/Gemsweeper
Mac.app/Contents/MacOS/Gemsweeper Mac"
Please note that I have already asked a similar question regarding the Xcode debugger here, but I am reposting since I just learned that this is in fact not Xcode's fault, but a problem with GCC / ld / GDB.
Edit: My project makes use of the following third-party libraries: SDL, Boost, wxWidgets. I am not sure if this matters for this problem, but I just wanted to mention it just in case it does.
I've tried compiling an Xcode SDL project template and did not experience the same problem, so it must be due to something special in my project.
Second Edit: As I just found out, I made a mistake while searching files with the string "This is an automatically generated". I just found several dozen files with the same string, all belonging to FreeImage, one of the third party libraries I am using. So, the problem seems to be related to FreeImage, but I am not still not sure how to proceed.
I got those symptoms, when my gdb version didn't match my g++ version.
Try to get the newest gdb.
Your cpp files certainly have debug symbols in them (the -gdwarf-2 option).
Do you use a separate dSYM file for the debug symbols? Or are they inside the object files. I would first try to use DWARF in dSYM files and see if that helps (or vice versa)
The third party libraries appear to be release builds though (unless you renamed them yourself of course) e.g. I know for sure boost uses the -d monniker in the library names to denote debug libraries (e.g. libboost_filesystem-mt-d.a).
Now, this shouldn't really pose a problem, it should just mean you can't step into the calls made to third party libraries. (at least not make any sense of it when you do ;) But since you have problems, it might be worth a try to link with debug versions of those libraries...
Are you compiling with optimization on? I've found that O2 or higher messes with the symbols quite a bit, making gdb and core files pretty much useless.
Also, be sure you are compiling with the -g option.
Can it be that you are using SDL? SDL redefines main so your main will be named SDL_main and that the SDL parts might be heavy optimized so down there you'll have problem getting good gdb output.
...just a thought
Read this
For a test, you could check if addr2line gives you expected values. If so, this would indicate that there's nothing wrong with the ELF generated by your compile/link parameters and casts all suspicion on GDB. If not, then suspicion is still on both the tools and the ELF file.
I've tried compiling an XCode SDL
project template and did not
experience the same problem, so it
must be due to something special in my
project.
Correct. Your project settings are the thing that is different.
You will need to disable the debug optimizations in the Xcode project settings for the debug build. Xcode unfortunately makes GDB jump to weird lines (out of order) when you would expect it to move sequentially.
Go to your project settings. Set the following
1) Instruction Scheduling = None
2) Optimization Level = None [-O0]
3) ZERO_LINK = None
Your problems should go after after doing this.
Here is the project settings screen that you need to change the settings on:
From your flags the debug information should be in the object files.
Does your project settings build the executable in one location then move the final executable to another location when completed? If this is the case then gdb may not be finding the objectects files and thus not correctly retrieving the debug information from the object files.
Just a guess.
I encountered this several years ago when transitioning from the Codewarrior compilers to Xcode. I believe the way to get around this is to put the flag "-fno-inline-functions" in Other C Flags (for Dev only).
This problem was more pronounced on the PowerPC architecture for us.
What about if you remove the "-fvisibility-inlines-hidden" and "-mfix-and-continue" flags?
I've never had the "fix and continue" feature work properly for me.
WxWidgets do also define their own main if you use their IMPLEMENT_APP() macro
From here
As in all programs there must be a "main" function. Under wxWidgets main is implemented using this macro, which creates an application instance and starts the program.
IMPLEMENT_APP(MyApp)
See my answer here
I have now downloaded and compiled the FreeImage sources and yes, the file b44ExpLogTable.cpp is compiled into libfreeimage.a. The problem looks like the script gensrclist.sh just collects all .cpp files without skipping the one with a main in. That script generates a file named Makefile.srcs but one is already supplied. (running it on my Leopard failed, some problem with sh - it worked if I changed sh to bash)
Before you have changed anything this gives an a.out
c++ libfreeimage.a
The file Makefile.srcs has already been created so you should be able to remove the file b44ExpLogTable.cpp from it. Then do
make -f Makefile.osx clean
make -f Makefile.osx
When this is done the above c++ libfreeimage.a should give the following error
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I have a new thing you can try.
Just before your own main you can write
#ifdef main
# error main is defined
#endif
int main(int argc, char *argv[]) {
this should give an error if you have some header that redefines main.
If you define an own you might get an warning where a previous definition was made
#define main foo
int main(int argc, char *argv[]) {
You can also try to undef just before your main
#undef main
int main(int argc, char *argv[]) {