Sun 03 Sep 2017 07:42:39 PM UTC, comment #18:
Yes, no work has been done on this and this is entirely a local configuration issue.
If someone installs a local version of Qt and their distribution also provides qtchooser, I think it's up to them to ensure that qtchooser works with their locally installed version of Qt.
|
Sun 03 Sep 2017 04:07:09 PM UTC, comment #17:
Can this bug report be closed? Most developers are now building with Qt5 successfully.
|
Thu 01 Sep 2016 02:14:12 AM UTC, comment #16:
From the description in "man qtchooser", it sounds as though that's what qtchooser is intended for. It doesn't seem so complicated relative to the many other configurations within the project.
To make the locally built Qt compatible with qtchooser only requires defining a file ~/.config/qtchooser/qt5.conf
/home/sebald/qt5build/qt5/bin
/home/sebald/qt5build
If there is no qtchooser installed, what to do? Don't know, but certainly something has to point Octave configuration to the utilities within the above local directories. The way I've done that is with something like:
PKG_CONFIG_PATH=/home/sebald/qt5build/qt5 ./configure
for any project that uses the autotools suite. I do see on my system some pkgconfig files for Qt5:
If there are some pkgconfig files appearing in the local Qt build, then perhaps no alteration is needed for Octave config if the PKG_CONFIG_PATH variable is pre-defined. This is the approach I needed to use when debugging OpenGL. I had to first build a bunch of up-to-date libraries that OpenGL uses, and I placed them all in /home/sebald/lib and the *.pc files went to /home/sebald/lib/pkgconfig. I had to keep pre-defining PKG_CONFIG_PATH to that same directory for about five libraries, then for the OpenGL build, then for Octave. After doing all that, I could then edit the OpenGL nuveau (or whatever) driver and change the driver behavior.
|
Thu 01 Sep 2016 12:57:20 AM UTC, comment #15:
I think that's way too complicated for what this is intended to do.
qtchooser is simply a drop-in proxy executable that is symlinked and used in place of moc, uic, etc.
The bug here is that if Octave sees qtchooser in PATH, then it assumes that moc, uic, etc are all symlinks to qtchooser. This falls apart in the corner case where you have a distro-installed version of Qt that uses qtchooser (where they are symlinks and everything normally works as expected), but you want to use a self-compiled version of Qt that is not configured for qtchooser, and you have set PATH to include /usr/local/lib/qt-whatever/bin containing the real executables.
I think configure should automatically discover whether moc, uic, etc, are actually using qtchooser or not, not require the user to add an option to force that kind of thing. And we should not need to set MOC to be something odd like "qtchooser --run-tool=moc", and we should not need to support additional arbitrary named configurations like "myqt5".
|
Thu 01 Sep 2016 12:38:08 AM UTC, comment #14:
I aware that we have to think the case mxe-octave.
On mxe-octave, qt-chooser is not taken into account.
Options
--with-qtchooser
--without-qtchooser
are candidates to solve this issue.
If --without-qtchooser is on, uic, rcc, moc, and lrelease are used as they are.
|
Wed 31 Aug 2016 04:02:43 PM UTC, comment #13:
Without reviewing, for brevity, let me just pose this question.
If the only issue is getting those moc, uic, proxies straight and the -qt5 flag is not something needed for compilation, is the proper route for Octave configuration to (instead of the -qt5 flag) redefine QT_CHOOSER in the configure script from
QTCHOOSER='qtchooser'
to
QTCHOOSER='qtchooser -qt=qt5'
or
QTCHOOSER='qtchooser -qt=qt4'
(or "5" and "4")?
I don't have time to investigate right now. Without the -qt4 or -qt5 flag, Octave still needs something to make the choice, so the QTCHOOSER needs to always be redefined (unless we want to leave it up to the user/builder to modify default.conf, but I don't think that is a good idea).
My thinking is that the user with local build should then define
~/.config/qtchooser/5.conf
~/.config/qtchooser/qt5.conf
and things are good so long as Octave configure recognizes there is a Qt5 version out there. (And the proper way to do so is probably through "qtchooser -l", not by searching for Qt libraries.)
And here's another question I have. Should Octave configure have some option like
--qtchooser=qt5local
so that QTCHOOSER can be redefined as
QTCHOOSER='qtchooser -qt=qt5local'
in which case the builder needs to place in their account the file
~/.config/qtchooser/qt5local.conf
?
|
Wed 31 Aug 2016 08:30:58 AM UTC, comment #12:
Dan
I did not write here why I built qt from source.
See the below
https://savannah.gnu.org/bugs/?48761
The qt-5.2.1, which is version in the ubuntu repository, seems to not enough new to build octave-gui as mentioned in the above tracker.
I have built octave-dev using qt-5.6.1 with workaround of Makefile of octave and gotten successful results.
To be honest, if qt is build from source,
octave configure hopefully pickups qt without using qtchooser.
On the LTS version, some libraries become out of date with developing newer version of applications.
On the occasion, there are situations that one has to build libraries from source.
I hope that octave configure takes into account such case.
|
Wed 31 Aug 2016 04:06:09 AM UTC, comment #11:
T.M., apparently the "qtchooser" pathway isn't necessary. But you need to create a ~/.config/qtchooser/default.conf:
But, I don't know if that helps Octave make any, because it is searching for qt5 first priority. It is only of benefit to you if you want to use these moc/uic commands directly.
If I'm understanding correctly now, the change you made, i.e., created ~/.config/qtchooser/qt5.conf, should work properly for the Octave configure because it will end up looking for qt5 version via
qtchooser -run-tool=XYZ -qt=qt5
in the Makefile. Is that correct Mike?
|
Wed 31 Aug 2016 03:38:01 AM UTC, comment #10:
Your list looks similar to mine. Hmm, I wonder if there is some way to get a new local entry into that list? Anyway, here's a link that indicates which conf file to change:
http://askubuntu.com/questions/435564/qt5-installation-and-path-configuration
Here's what I'm seeing on my system:
Oh hey, I wonder... yes, I see. I just placed a new file in that directory and that shows up in the list, and I did the same in the ~/.config/qtchooser directory:
This all seems to work fine.
T.M., when you use the following command
moc -qt5
you are bypassing qtchooser. Whatever you set ~/.config/qtchooser/qt5.conf to has no bearing on the above command. After setting ~/.config/qtchooser/qt5.conf, you need to run
qtchooser -run-tool=moc -qt=qt5 -v
Or, you can call the conf file something other than qt5.conf, as I've illustrated above.
The question for Octave make is, Should there be a pathway for the builder to specify at qtchooser version other than 4/5 so that local Qt builds can be used as I've illustrated above? Or, should it fall back to the "PKG_CONFIG_PATH=/somepath/pkgconfig ./configure" approach?
|
Tue 30 Aug 2016 11:27:19 PM UTC, comment #9:
Reply to comment 7
I executed
qtchooser -l
qtchooser -run-tool=uic -qt=5 -v
qtchooser -run-tool=uic -qt=4 -v
$ qtchooser -l
4
5
default
qt4-x86_64-linux-gnu
qt4
qt5-x86_64-linux-gnu
qt5
$ qtchooser -run-tool=uic -qt=5 -v
uic 5.2.1
$ qtchooser -run-tool=uic -qt=4 -v
Qt User Interface Compiler version 4.8.7
Setting of ~/.config/qtchooser/qt5.conf seems not to work.
|
Tue 30 Aug 2016 11:21:53 PM UTC, comment #8:
Reply to comment #6
I have reinstalled self-build qt5 to /usr/local/qt-5.6.1 and set
~/.config/qtchooser/qt5.conf
and execute
moc -qt5
but moc hangs.
|
Tue 30 Aug 2016 05:37:22 PM UTC, comment #7:
From https://savannah.gnu.org/bugs/?48881#comment1
"
This does not work in the case that you have, where qtchooser is installed and configured to work with the Qt versions installed from the Ubuntu repositories, but you have also installed a local version of Qt and set PATH appropriately.
One workaround would be to figure out how to configure the qtchooser program to use your locally installed copy of Qt.
"
The qtchooser doc suggests that locally installed versions should be included:
http://manpages.ubuntu.com/manpages/wily/man1/qtchooser.1.html
"The Qt Chooser provides a wrapper to switch between versions of Qt development binaries when multiple versions like 4 and 5 are installed or local Qt builds are to be used."
Of course, it doesn't say exactly how to do that.
Also, depending upon what tools are used to build Qt, there is often a package directory that can be set prior to make, e.g.,
PKG_CONFIG_PATH=/home/sebald/local/lib/pkgconfig ./configure --prefix ~/local --with-llvm-prefix=/home/sebald/local --disable-llvm-shared-libs
in which case all of the info about where the tools/libraries, etc. are contained is in the pkgconfig directory. When I built OSMesa on my old system, I had to do this with about four or five software projects to get the latest of everything. Does T.M. simply need to add the proper PKG_CONFIG_PATH for the local Qt prior to the Octave ./configure?
Anyway, I'd still be interested in seeing what T.M. sees for
qtchooser -l
qtchooser -run-tool=uic -qt=5 -v
qtchooser -run-tool=uic -qt=4 -v
and how it is that qtchooser should be able to work with locally installed Qt.
|
Tue 30 Aug 2016 05:13:46 PM UTC, comment #6:
Please look at configure, we already use qtchooser. The problem experienced on Tatsuro's system is with a version of Qt that is built from source and installed outside of the distro packaging system. Octave's configure detects that qtchooser is installed, tries to add the correct options to use it correctly, but the version of Qt that Tatsuro has built and wants to use does not work with qtchooser.
As I showed in comment #2, a ~/.config/qtchooser/qt5.conf might be useful on such a system to get it to use the Qt installed from source. Tatsuro has not yet replied whether something like that works or not.
|
Tue 30 Aug 2016 06:29:55 AM UTC, comment #5:
I wasn't aware of the qtchooser program, but checking for that first is probably the way to go. If it is present, then use that to determine what Qt versions are present and run through that rather than directly. I think qtchooser is meant to save doing some work.
For example, on my system, I have both Qt 4 and 5. Running "uic -v" I get:
So, the search path first finds Qt 4 tools. I think qtchooser indicates that it will first find version 4:
Any of those entries in the list must be acceptable for choosing, and they all boil down to either the version of Qt4 installed or the version of Qt5 installed. Let's run uic indirectly then:
which is same as directly. But if I specify which version
We should be able to replace "uic" in the Makefile with ["qtchooser -run-tool=uic -qt=" QTVERSION] if we know qtchooser is present. And to get QTVERSION, parse "qtchooser -l" output I guess.
T.M., could you run some of the things I did above and tell us what you see? Try
qtchooser -l
qtchooser -run-tool=uic -qt=5 -v
qtchooser -run-tool=uic -qt=4 -v
|
Fri 26 Aug 2016 04:44:10 PM UTC, comment #4:
They are all over the place.
Both Qt 4 and Qt 5 rcc and uic will take either '-v' or '-version' options.
Qt 4 moc will take a '-v' or '-version' option, but Qt 5 moc will not accept '-version'.
The lrelease tool only takes a '-version' option for both Qt 4 and Qt 5.
The version string goes to stdout for lrelease (both 4 and 5), and for Qt 5 moc, rcc, and uic, but to stderr for Qt 4 moc, rcc, and uic.
And as for the '-qt4' or '-qt5' option, all of them flag it as an error when combined with '-v' or '-version' as appropriate, except Qt 4 uic which happily accepts it and prints its version.
|
Thu 25 Aug 2016 02:43:49 PM UTC, comment #3:
Should we try to determine the version of uic, rcc, moc, and lrelease? They all seem to support a -version option. Unfortunately, they don't all print out version info in the same format...
|
Wed 24 Aug 2016 12:15:36 AM UTC, comment #2:
To configure qtchooser, place a file like the following in your $HOME/.config/qtchooser directory:
Then qtchooser's symlinks should be able to find the correct paths to the real programs without having to add them to PATH.
|
Tue 23 Aug 2016 11:58:23 PM UTC, comment #1:
It looks to me like the configure script checks for a program called "qtchooser" in the system PATH.
If qtchooser is found, then it assumes that it must be in charge of all of the Qt helper programs.
This does not work in the case that you have, where qtchooser is installed and configured to work with the Qt versions installed from the Ubuntu repositories, but you have also installed a local version of Qt and set PATH appropriately.
One workaround would be to figure out how to configure the qtchooser program to use your locally installed copy of Qt.
Another workaround would be to uninstall the qtchooser package, but that's probably not practical.
One fix for configure might be to try running
and see whether it exits with success or failure (notice the different option on lrelease).
However, uic seems to take the -qt4 or -qt5 option with -v, so I don't see that working very well.
Any other ideas how to detect whether $UIC is actually qtchooser without going into complicated or system-dependent checking?
|
Tue 23 Aug 2016 11:36:16 PM UTC, original submission:
System : Ubuntu 14.04 amd64
Compiler : gcc 5.3.0
Octave version : 4.1.0+
Qt version : 5.6.1
How to get qt : build from source.
Related mailing list : below URL
http://octave.1599824.n4.nabble.com/Unknown-option-qt5-GEN-libgui-src-ui-settings-dialog-h-td4679396.html
"make V=1" told
As Mike wrote in the ML,
I needed to erase the value "-qt5" from UICFLAGS, RCCFLAGS, MOCFLAGS, and LRELEASEFLAGS in Makefile to build octave.
This issue is due to current configuration not taking into account the case that uic, rcc, moc, and lrelease are not proxy but real ones.
|