qmake using 4.8 always returns "Project ERROR: Failed to determine build specification for platform!"

SGaist

Is your Qt 4 build old ?

nickb

Old? It's qt 4!
Seriously though, what do you mean by old? I built the one on my machine from source the other day. The same situation on my colleague's machine, is using a build our company built a long time ago and is checked in to a repo.

koahnig

@nickb
SGaist refers to an old build of the library. E.g. an old build with an older compiler version and libs which have been updated afterwards.

I am not sure if does matter as much on Linux, but windows you have to be really careful with compiler versions. Every MS compiler version has a different memory model. However, also GCC (MinGW called there) version are not always compatible.

AFAIK Qt 4.8.0 was released around the same time or a bit later as Qt 5.0. Therefore, I believe GCC version have changed as well on linux IRC.

Probably the best way is to recompile Qt 4.8 from recent source downloaded with your current compiler installed. This would avoid such compatibility issues.

nickb

Yeah, we build all of our qt libs from source. And on windows we are very particular about the MSVC versions all of our software is built against.
This specific issue is on linux only.I have this problem with the qt4.8 that I built from source recently and with the build we get out of our repo, which I guess you could describe as old. Being that we are fairly used to developing with qt 4.8 for a long time and qt 5.X is relatively new for us, it seems this problem only occurred after using qt 5 and then trying to switch back.
Could qt 5 have made some environmental change to our machines that prevents the older qmake from working anymore? Is there a more nuanced test I could do on qmake; ie how should it be determining the build spec for the platform?

SGaist

It should not (unless someone did something unusual when installing). First thing I'd check is which qmake to see which one is used. From there verify the install/mkspecs of that version.
Then I'd verify if there's several *.pro.user in the sources and removed them (just remember that if you have special settings for your projects, move the files away so you can have a mean to get these back).

nickb

when i try to use the 4.8 qmake from the commandline I set the 4.8 bin folder to the beginning of my env PATH, and also set QTDIR to the 4.8 installation which is in /usr/local/Trolltech. "which qmake" does show the 4.8 one.

SGaist

One thing that is puzzling me is that "bits/c++config.h: No such file or directory" error is generally happening when cross-compiling...

nickb

So, theoretically, when using 2 different qt builds on a single machine, in order to run qmake for a given qt build, you simply need to call the appropriate qmake that is in the bin folder of the build you want?
Like in qtcreator, in order to add another qt version, you simply need to find qmake for the version you want, and it figures out the rest?

SGaist

Yes, e.g. for Qt 4

cd myProject_shadowbuild
/usr/local/Trolltech/Qt4.8.7/bin/qmake -r /path/to/myProject
make -j99

nickb

I'm almost at the point of needing to debug qmake itself! Do you know what mechanism it uses to determine the platform? Surely when I built the qt framework in the first place, at that point it would determine the platform it was on, assuming I wasn't trying to cross compile it? Maybe the "bits/c++config.h" error is a clue then, when I built it did I make it think it was building for another platform somehow?

SGaist

configure handles that for you unless you specify something yourself. I'm thinking of something, are you trying to build a 32bit application with a 64bit Qt ?