Creator uses g++ although I have specified arm-linux-g++
I have set up a toolchain to compile for an embedded device. My problem is twofold:
- Creator persists in using g++ as compiler instead of arm-linux-g++
- The ARCH environment variable is not set correctly, therefore the wrong platform-specific sections of my project file are used.
Here's how I set things up:
I already have a Qt version that is set up correctly - I can compile for the device on the command line after executing the following script:
echo "R9: now compiling for arm target qt 4.7.3"
set qt dirs
set cross compiler defs
I have added this Qt version to Creator.
I have then tried setting up a toolchain so that I can compile (and hopefully one day remote debug) the embedded device with Creator.
In the toolchain, I have specified as compiler path:
and as debugger path:
The ABI detected is arm-linux-generic-elf-32bit
As Qt version, I have specified
which is exactly the version that works when compiling on the command line.
I opened the project and selected the correct Qt version. On the "Project" page, I can see the correct tool chain displayed. Nevertheless I have the problems mentioned above.
Any ideas? I have basically taken the blog about "raspberry-pi":http://labs.qt.nokia.com/2012/01/19/raspberry-pi-a-case-study-in-deploying-qt-apps-to-generic-linux-devices/ and modified to my device. I don't see that I have forgotten any major step.
Any ideas where I might have gone wrong?
Creator is most likely trying to use the wrong mkspec.
Please try adding
as an argument to the qmake step on the Projects->Build Settings page.
[EDIT: code formatting for args to avoid strikethrough, Volker]
Yes, that does the trick. Thanks!
I get the warning
@The tool chain suggested "linux-g++-32" as mkspec@
Is there a way to specify this in the toolchain, so I don't have to do it for each project?
Not yet, sorry.
In this case, is there a way to put it into my .pro file, so I am not dependent on the .user file?
(The .pro file is shared among our team. The .user file is private to each developer)
No, you can not put the mkspec into the .pro-file.
You could try using a .shared file. That is basically a shared preset file that can contain anything that is also contained in the .user file. I am not sure how much that really helps, the whole thing is rather new and not used widely yet. We would appreciate feedback on this:-)
By the way: How do you share the tool chains?
Thanks for the info!
I do not currently share the tool chains. Right now, I just try to get it running on my machine. But I am already thinking ahead. Not having to make changes in each and every Creator project would reduce potential errors.
Once I have it running here, I might try out the shared project file.
This used to work correctly on Qt Creator versions prior to 2.3. It was broken in that version and although it has been reported as such it has not been fixed as yet. The basic problem is that prior versions used to use qmake to determine the mkspec whereas Qt Creator 2.3+ insists on overriding that mkspec with the incorrect one. The only solution at this time is to add the -spec argument manually for each project.
I want a big, fat checkbox somewhere in Creator options, called "Stick to what the .pro file and Creator settings say. No overrides"
It's not like it's the first time Creator tries to outsmart me.
Well, the reason I have creator now use the mkspec that the tool chain suggests is that this allows to switch toolchains. This was not possible at all in Qt Creator <2.3 (or was that 2.2?). Then the tool chains were used to decide how to parse the output only and changing them did not change the mkspec used to build (so the tool chain was actually not switched). Lots of people complained about that, so I added switching the mkspecs. Now we get much fewer people complaining because this does break some cross-compiling setups.
Having said that, I do need to do something to improve the situation for the cross-compiling people. I am thinking of not overriding the mkspec of QMake if the compiler set in the toolchain is not used in the toolchain's mkspec... The problematic bit is getting the information on what is set in the mkspec in the place where I need to decide which mkspec to suggest. I'll might find the time to look into this later this week. Anyone volunteering to test? ;-)
Sure, I'll test it. There's another whole bunch of issues regarding specifying toolchains manually, but let's deal with one issue at a time... ;)
Qt4iOS: http://codereview.qt-project.org/#change,15027 is something for you:-) It allows overriding the suggested mkspec of a tool chain.
I still want a review for that one though before I can commit it to master.
Thanks, I'll see if I can test it today...
Ok, took a few days to get to test this, but I can confirm that the mkspec now defaults to 'default' instead of trying to guess the mkspec (which surely would be easy enough by just examining where 'default' points to?). The new 'toolchain->mkspec' and 'unconfigured project' settings will remove a few steps when setting up a new project... Thanks! :)
The patch is in master now. Thanks for the testing!