Closed n3rdopolis closed 9 years ago
On my system /opt/bin/lrelease doesn't take the -qt5 option because it is the qt5 version....
Uhm... here i can pass -qt5 both to /usr/bin/lrelease, which is a link to qtchooser, and to /usr/lib/qt(4)/lrelease, which is the actual binary. Both the one from qt4 and qt5 accept -qt* options, so not sure what is the issue...
Maybe it's an issue with qt5.5... It seems to be a binary on mine. When I try to build it against qt5.5, I get help output on command line usage for lrelease in the build log, and then the build fails... ...unless I change that Cmake file....
I should have mentioned it was qt5.5...
The exact Qt version shouldn't matter, if it does it's a bug in Qt. My understanding is that if you don't have qtchooser you'll have the actual binaries in /usr/bin, the ones i have in /usr/lib/qt/bin, or maybe they'll be links to there. Not having qtchooser should be supported, but being unable to reproduce your problem i'm not sure how to fix it.
not sure why. I have /usr/bin/qtchooser, but my /opt/bin/lrelease is a file, and not a symlink... must be my qt configuration....
What is the output of "qtchooser -l"?
4 5 default qt4-i386-linux-gnu qt4 qt5-i386-linux-gnu qt5
Ah, but hang on, i think we're looking at the wrong thing. You said that you're getting the help output from lrelease, not something like "lrelease: could not find a Qt installation of '5'"? If so, what does "whereis lrelease" say?
Correct. it seems lrelease prints the help when it doesn't know an argument passed to it? whereis lrelease /usr/bin/lrelease /opt/bin/lrelease
which lrelease /opt/bin/lrelease
Interestingly enough the one in /usr is a symlink to qtchooser, but not in /opt
Actually... maybe I should just remove the -qt5. If someone needs for it to specified he should use the QT_SELECT env variable...
On my system /opt/bin/lrelease doesn't take the -qt5 option because it is the qt5 version....
I have to apply this patch to get it to compile and install