(resolved) getting Creator to "pick up" new version of GCC
-
Creator picks up the first GCC it discovers in PATH automatically. So put /opt/local/bin to the front and it should find that one.
I'd just set up a tool chain manually though.
-
Thanks, Tobias. I'm not ignoring your suggestion to set it up manually, but I want to see that I can get it to work automatically first. I just rearranged my PATH variable, but it still picks up the compiler in /usr/bin. This tells me that one of two things is happening:
- I screwed up the install (possible, though I used Macports and it seemed OK)
- Creator is looking for a specific filename that it's not finding, so maybe I need to make a link.
Do either of these seem likely to you?
EDIT:
Here are (at least some of) the files produced by macports. According to a thread I read (not in Qt-land), these are what to expect.
bq. mac mini:~ mzimmers$ cd /opt/local/bin
mac mini:bin mzimmers$ ls gcc*
gcc-ar-mp-4.7 gcc-nm-mp-4.7
gcc-mp-4.7 gcc-ranlib-mp-4.7
mac mini:bin mzimmers$ ls g++*
g++-mp-4.7
mac mini:bin mzimmers$I also tried making a link in /opt/local/bin:
@mac mini:bin mzimmers$ sudo ln g++-mp-4.7 gcc
@and made a similar link for "g++", but Creator is still picking up the other version (4.2 in /usr/bin) instead.
Here's my PATH variable:
@mac mini:bin mzimmers$ echo $PATH
/opt/local/bin:/opt/local/sbin://usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:.:/opt/local/lib:/Developer/Applications/Qt/Desktop/Qt/4.8.0/gcc/bin:/opt/subversion/bin:/usr/local/Cellar/boost/1.49.0/include/boost
ma@So...do I need to do something to get creator to re-examine the paths to the tool chains? Restarting it doesn't seem to do anything.
-
Restarting should cause Creator to pick up the PATH. Does "which g++" find the right thing?
-
Creator will set the path for the executable to be picked up. Unfortunately qmake will ignore the actual binary specified and fall back to whatever is encoded in its mkspec:-( So you will need to make sure the compiler executable is actually the one the mkspec will run.
I am not really happy with the current state of the tool chains and qmake integration, but do not see much I can do at this time to improve the situation in time for 2.5:-( For 2.6 we are already planing to improve the situation a lot.
-
bq. Unfortunately qmake will ignore the actual binary specified and fall back to whatever is encoded in its mkspec:-( So you will need to make sure the compiler executable is actually the one the mkspec will run.
So, how do I go about doing that? With a manual addition to the tool chain? Or do I need to create a mkspec directory for the new compiler(s)? (Is there documentation on how to do the latter, by the way? I couldn't find any.)
-
You will need copy one of the directories in QTDIR/mkspecs (choose one close to what you want to use) and then edit the files in that directory.
-
Yes, I understand that (I think), but...then what?
I'm trying to understand the whole process of introducing a new mkspec directory into the build process. So:
- by creating this directory, how does Creator find it?
- are there any naming conventions I should be aware of?
- will it get overwritten/deleted/lost when I update Qt at some point? I notice the mkspec directories are under a directory named "4.8.0" so I imagine this must be a concern somehow.
Come to think of it...this is all under a directory called "gcc." So, for non-gcc compilers (like LLVM), should I create a parallel directory path, and if so, how many of the files from gcc would I need?
Lots of questions...so much I don't know...
-
There are LLVM mkspecs in unsupported (use them via -spec unsupported/whatever) already.
Creator will find all the mkspecs that are available in the Qt version you selected. IIRC you can also specify a absolute path to mkspecs somewhere else.
You will need all the files you end up using:-) Stupid answer, I know, but it depends a lot on how you define the mkspec. Just check existing ones and use them as examples.