bugGNU Octave - Bugs: bug #40252, Make GUI compatible with both Qt4...


bug #40252: Make GUI compatible with both Qt4 and Qt5

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Sat 12 Oct 2013 07:40:35 PM UTC  
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 11 Aug 2016 06:21:43 AM UTC, comment #32:

On Fedora, try

$> pkg-config --list-all

and check if qscintilla appears somewhere in the list. (There is no package config file/info for Mint/Ubuntu.)

Dan Sebald <sebald>
Thu 11 Aug 2016 03:58:21 AM UTC, comment #31:

Dmitri - please open a new bug about the Qscintilla library naming convention differences.

And feel free to investigate the font differences between Qt 4 and 5. I do notice a difference in the widget fonts, not the command window font, when I bring up the GUI on my Debian system, but I guess I just don't care enough personally to play with it.

Mike Miller <mtmiller>
Project Administrator
Thu 11 Aug 2016 03:29:09 AM UTC, comment #30:

Here is my findings sofar:

-- Qt5/Qt4 linking was due to octave-4.0.3 installed system-wide.

since it linked to Qt4 it pulls those Qt4 links in. If I remove octave from the system, the Qt4 links dissapear as well. In any case those do not seems to affect anything.

-- clipping fonts in command history window appears to be an issue with Qt5 and cleartype fonts. If I change the fonts to TT (systemwide), the problem disappear.
Not sure if this is a problem with octave or Qt5. octave-gui compiled against Qt4 can handle both ClearType and TrueType.

-- On Fedora, the name of Qt5-linked qscintilla library is
libqscintilla2-qt5.so. Configure does not find it. I had to make
symlink to libqt5scintilla.so. Agin not sure if there are naming conventions and is this an octave or fedora issue.


Dmitri A. Sergatskov <dasergatskov>
Wed 10 Aug 2016 07:40:43 PM UTC, comment #29:

ldd will tell you the full recursive list of libraries that the loader will pull in to the process when the shared object is loaded. It doesn't tell you why.

readelf -d will list just the shared objects that the given executable or library declare that they depend on.

You can use cat /proc/$pid/maps to see the shared libraries that are actually loaded in the running process image.

Mike Miller <mtmiller>
Project Administrator
Wed 10 Aug 2016 07:40:30 PM UTC, comment #28:

make V=1
HG-ID is unchanged
rm -f bits/stl_algo.h
make all-recursive
make[1]: Entering directory '/home/dima/src/octave/gcc_qt5'
HG-ID is unchanged
Making all in libgnu
make[2]: Entering directory '/home/dima/src/octave/gcc_qt5/libgnu'
make all-recursive
make[3]: Entering directory '/home/dima/src/octave/gcc_qt5/libgnu'
make[4]: Entering directory '/home/dima/src/octave/gcc_qt5/libgnu'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/dima/src/octave/gcc_qt5/libgnu'
make[3]: Leaving directory '/home/dima/src/octave/gcc_qt5/libgnu'
make[2]: Leaving directory '/home/dima/src/octave/gcc_qt5/libgnu'
make[2]: Entering directory '/home/dima/src/octave/gcc_qt5'
HG-ID is unchanged
/bin/sh ./libtool --tag=CXX --mode=link g++ -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -no-undefined -o src/octave-gui src/src_octave_gui-main-gui.o src/src_octave_gui-octave-build-info.o libgui/liboctgui.la libinterp/liboctinterp.la liboctave/liboctave.la libgnu/libgnu.la -lutil -lm
libtool: link: g++ -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -o src/.libs/octave-gui src/src_octave_gui-main-gui.o src/src_octave_gui-octave-build-info.o libgui/.libs/liboctgui.so /home/dima/src/octave/gcc_qt5/libinterp/.libs/liboctinterp.so -lQt5Network -lQt5OpenGL -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Core libinterp/.libs/liboctinterp.so /home/dima/src/octave/gcc_qt5/liboctave/.libs/liboctave.so -lhdf5 -lGraphicsMagick++ -lGraphicsMagick -lz -lGL -lGLU -lfontconfig -lfreetype -lX11 -lgl2ps liboctave/.libs/liboctave.so -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -lopenblas -lreadline -lncurses -lpcre -ldl -lgfortran -lquadmath libgnu/.libs/libgnu.a -lutil -lm -fopenmp -pthread -Wl,-rpath -Wl,/usr/local/lib/octave/4.1.0+
rm -f src/octave-gui-4.1.0+ && \
cd src && ln -s octave-gui octave-gui-4.1.0+

Octave successfully built. Now choose from the following:

./run-octave - to run in place to test before installing
make check - to run the tests
make install - to install (PREFIX=/usr/local)

HG ID for this build is "945e7f9c11ff"

Dmitri A. Sergatskov <dasergatskov>
Wed 10 Aug 2016 07:36:58 PM UTC, comment #27:

I'm not seeing the problem with mixed library versions. I see this:

If you delete the src/octave-gui file, what does "make V=1" tell you about linking with -lQt* libraries? Likewise for the liboctgui library link step.

John W. Eaton <jwe>
Project Administrator
Wed 10 Aug 2016 07:25:09 PM UTC, comment #26:

At this moment I am not sure if ldd src/.libs/octave-gui
is meaningful. run-octave and/or seems to do some relinking
magic which may change how symbols are resolved.
Is there an easy way to check which shared libraries are used
by an actual running process? After executing run-octave,
I did

and that looks OK.


Dmitri A. Sergatskov <dasergatskov>
Wed 10 Aug 2016 07:06:54 PM UTC, comment #25:

Oh, but hold off creating a bug report if you have Qt4 and Qt5 libraries intermixed. That may be the source of error (i.e., wrong font/font-metrics in some library).

Dan Sebald <sebald>
Wed 10 Aug 2016 07:06:12 PM UTC, comment #24:

Dmitri - yes, please report a separate bug about overlinking to both Qt 4 and Qt 5. I do not see this on Debian. Please include details about whether liboctgui.so links with those libraries directly or whether they are linked via another dependency if you can.

Dan - if you have access to a newer version of GCC 5 or 6, please try that if you can and see if the error follows. Maybe you should report your compilation error as a new bug anyway, this bug being about enabling the code and the right build options, which seems to be completely done now.

GUI appearance / quality with Qt 5 can be yet another bug report.

Mike Miller <mtmiller>
Project Administrator
Wed 10 Aug 2016 07:01:22 PM UTC, comment #23:

Yes, that should be a separate bug report. It appears as though the font size is too large, or the bitblit to graphics memory is filling in white background when it should just be the glyph. Notice how each line overwrites the line above it--the bottom line looks good.

Dan Sebald <sebald>
Wed 10 Aug 2016 06:54:12 PM UTC, comment #22:

May be we should make a different bug for this...
The command history with Qt5 look bad -- line spacing is not quite right (I attached a screenshot). The same hg head with Qt4 looks fine.

(file #38169)

Dmitri A. Sergatskov <dasergatskov>
Wed 10 Aug 2016 06:28:52 PM UTC, comment #21:

GCC 4.8, correct:

sebald@ ~/ $ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4

Dan Sebald <sebald>
Wed 10 Aug 2016 06:26:57 PM UTC, comment #20:

It builds (and run) for me on FC24, though the following looks

It looks to me it mixes 4 and 5.


Dmitri A. Sergatskov <dasergatskov>
Wed 10 Aug 2016 06:26:03 PM UTC, comment #19:

So the only errors are about the use of the deleted QBasicAtomicPointer::operator= ? Could this be a compiler version problem? GCC 4.8 right? It looks to me like GCC is complaining about the assignment operator being deleted when doing

which should be an initialization, not an assignment (if I understand enough C++11).

Mike Miller <mtmiller>
Project Administrator
Wed 10 Aug 2016 06:15:36 PM UTC, comment #18:

Well, it wasn't a fresh clone, per se. Just a fresh build tree. I could step back further and do a clone.

My version of Qt5 is 5.2.1.

I have qtbase5-dev, qtbase5-dev-tools installed, but that is all in the qtbase5 camp. None of the other Mint packages seem relevant though.

I don't have libqt5scintilla2-dev package installed. That is probably why I'm getting the "unused option -p" warning that you just fixed. I'll install that and do a rebuild...

Dan Sebald <sebald>
Wed 10 Aug 2016 05:56:08 PM UTC, comment #17:

Starting with a fresh clone will be as good as 'make maintainer-clean'.

What version of Qt5 are you using?

Also, do you have qtbase5-dev, qtbase5-dev-tools, libqt5scintilla2-dev installed (or something similarly named?)

Rik <rik5>
Project Administrator
Wed 10 Aug 2016 05:44:28 PM UTC, comment #16:

I'm having problems with Qt5 build.

First, I had to run ./bootstrap in order to update "configure" so that the "5 4" appeared. I ran configure to verify it was Qt5 tools used everywhere. I did make and then upon reaching libgui got many errors because "moc" files were all generated using Qt4. So I deleted the build tree and started from "configure" again.

Now what I'm seeing is many repeated errors:

/home/sebald/octave/octave/octave/libgui/qterminal/libqterminal/unix/KeyboardTranslator.h:101:26: error: use of deleted function 'QBasicAtomicPointer<X>& QBasicAtomicPointer<X>::operator=(const QBasicAtomicPointer<X>&) [with X = KeyboardTranslatorManager]'
k_static##NAME = 0; \
/home/sebald/octave/octave/octave/libgui/qterminal/libqterminal/unix/KeyboardTranslator.h:61:37: note: in expansion of macro 'K_GLOBAL_STATIC_WITH_ARGS'
/home/sebald/octave/octave/octave/libgui/qterminal/libqterminal/unix/KeyboardTranslator.cpp:892:1: note: in expansion of macro 'K_GLOBAL_STATIC'
K_GLOBAL_STATIC( KeyboardTranslatorManager , theKeyboardTranslatorManager )
In file included from /usr/include/qt5/QtCore/qatomic.h:47:0,
from /usr/include/qt5/QtCore/qglobalstatic.h:47,
from /usr/include/qt5/QtCore/qglobal.h:1034,
from /usr/include/qt5/QtCore/qchar.h:45,
from /usr/include/qt5/QtCore/qhash.h:45,
from /usr/include/qt5/QtCore/QHash:1,
from /home/sebald/octave/octave/octave/libgui/qterminal/libqterminal/unix/KeyboardTranslator.h:28,
from /home/sebald/octave/octave/octave/libgui/qterminal/libqterminal/unix/KeyboardTranslator.cpp:25:
/usr/include/qt5/QtCore/qbasicatomic.h:258:26: error: declared here
QBasicAtomicPointer &operator=(const QBasicAtomicPointer &) = delete;
make[2]: *** [libgui/qterminal/libqterminal/unix/libgui_qterminal_libqterminal_la-KeyboardTranslator.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I think I've covered "maintainer-clean" having started a build tree from scratch.

I will continue to look at this. The only clue I have right now is that the code in KeyboardTranslator.h at line 101 and 61 is macro code and it has a comment about KDECORE relevance. I'm not using KDE though. Mint Rosa is GNOME 3, I believe. Anyway, this long string of errors is probably what I saw initially when I tried to manually build with Qt5. This KeyboardTranslator.h header file gets included everytime a file is compile, apparently.

Dan Sebald <sebald>
Wed 10 Aug 2016 04:22:44 PM UTC, comment #15:

I verified that I can compile with Qt4 or Qt5, and that liboctgui.so is correctly linked to the appropriate libraries. I checked in a changeset to silence a compiler warning about an unused parameter if HAVE_QSCINTILLA is false (http://hg.savannah.gnu.org/hgweb/octave/rev/daa81db564ac).

Closing report.

Rik <rik5>
Project Administrator
Wed 10 Aug 2016 08:18:36 AM UTC, comment #14:

I'm able to build with either Qt4 or Qt5 after the following changesets:


By default, configure will now check for Qt5, then Qt4. To build with Qt4 even if Qt5 is installed, use the configure option

John W. Eaton <jwe>
Project Administrator
Mon 08 Aug 2016 12:35:20 PM UTC, comment #13:

The patched version of octave from http://www.pkgsrc.org:


builds and runs with Qt5.

Patrick Welche <prlw1>
Mon 02 May 2016 05:45:27 PM UTC, comment #12:

This looks like a good place to comment on my experience compiling under Linux Mint and only having Qt5 installed. I will write a summary below, but the executive summary is that I think it would make sense to put the configuration in place for Qt5 or Qt4 and not worry about how Qt5 compiles for the moment. Those having Qt5 installed can easily help with debugging. (I quit when running into all sorts of compilation errors under Qt5, but they seemed very repetitive with the same error showing up time and again.) However, if Qt5 is selected, be sure to have a message like

WARNING: Qt5 has been selected, but Qt5 support is in development and those wanting a stable version should select option --with-qt=qt4.

The reason is that the GUI is compiled way at the end, so a message would avoid an hour of recompiling.

Also, I'd say judging from the changeset that Rik removed, that Octave might not be going about this configuration as sleekly as it could. gnuplot seems to have it right with simply basing Qt5 lrelease, uic, rcc and moc off of the pkg-config result for searching for package Qt5Core, etc. The reason is I'm not sure that uic-qt5 will ever exist because I think package managers have organized Qt5 a bit differently. I think it is rather straightforward to just first check for Qt5Core, etc., and if that exists then check for [qt5 base]/bin/lrelease, etc. If those aren't present then give an error. Don't rely on the /usr/bin/uic, etc. because that seems to be tied directly to the Qt4 sources, even if Qt4 isn't installed.

OK, below is my summary, and I'll attach a short diff file of changes I made.

(file #37049)

Dan Sebald <sebald>
Sun 19 Apr 2015 05:34:42 PM UTC, comment #11:

Since Octave is not ready to support Qt5 I've removed the configure checks for it here (http://hg.savannah.gnu.org/hgweb/octave/rev/d58ba8b9f709).

Rik <rik5>
Project Administrator
Sat 21 Feb 2015 10:11:35 PM UTC, comment #10:

Yeah, that's probably a good idea.

I don't even see a moc-qt5 on my Debian system with both Qt4 and Qt5. Instead Debian uses a package called qtchooser to dispatch to one of the two versions.

Mike Miller <mtmiller>
Project Administrator
Sat 21 Feb 2015 10:06:54 PM UTC, comment #9:

Currrently, configure looks for qmake-qt5, then qmake-qt4 and then qmake, the same with the other qxxxx tools.

Since it is not working for qt5 (yet) should qt5 be taken from the configure checks?

John Donoghue <lostbard>
Project Member
Sat 21 Feb 2015 08:25:20 PM UTC, comment #8:

I've got this partially done, but the hard part of this bug is the configuration part. When do we decide to use Qt 4 or Qt 5? Automatically prefer Qt 4 and fall back to Qt 5 if 4 isn't working, or vice versa? Or supply a user option to pick one or the other?

We will need different sets of pkg-config modules for each (e.g. QtGui vs Qt5Gui), potentially different sets of helper programs (e.g. moc-qt4, moc-qt5, or just moc).

Since I think all distributions will continue to have Qt 4 for a long time to come, I'm going to put this off until after the 4.0 release.

Mike Miller <mtmiller>
Project Administrator
Tue 03 Feb 2015 04:30:25 PM UTC, comment #7:

Thanks, I will do what I can.

I don't think any distros are shipping Qt 5 to the exclusion of Qt 4, but please do comment here if I'm wrong. Fedora 21, Ubuntu 14.10, and RHEL 7 all offer Qt 5 as an option, but Qt 4.8 is also provided. So I don't think it's as important as other bugs, but would be nice to release with at least the possibility to build against Qt 5.

Mike Miller <mtmiller>
Project Administrator
Tue 03 Feb 2015 04:00:31 PM UTC, comment #6:

@Mike: I marked this bug as In Progress. I just checked and Fedora 21 and Ubuntu 14.10 are both shipping with Qt5 so I think this is important to resolve for the next release.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 04:43:25 AM UTC, comment #5:

I revisited this bug again for a little bit tonight. I made some headway, and finally got Octave to build against Qt 5.3.

Attaching a diff of all the quick-n-dirty changes I had to make. Some of these are backwards compatible with Qt 4, some of these are new or renamed functions in Qt 5, some will need #ifdefs, etc. But it does compile and the GUI does come up.

I'm willing to pick this up again and work out the remaining issues, just wanted to share what I have for now.

Also worth noting that I had to manually mess with the include and library flags. So configure.ac will need some work as well, not included in this diff at all yet.

(file #32978)

Mike Miller <mtmiller>
Project Administrator
Sun 07 Dec 2014 07:06:03 AM UTC, comment #4:

Until this is done, can the Qt5 detection in configure.ac be turned off?


Sat 02 Nov 2013 01:32:46 AM UTC, comment #3:

Many more errors, a handful of member functions have been deprecated or removed with Qt5. I haven't gotten all the way through it yet, but here's a sample of what I've worked through so far:

And the appropriate pkg-config modules are (at least on Debian):

Marking as postponed for now, this looks pretty disruptive and unnecessary at this point in time.

Mike Miller <mtmiller>
Project Administrator
Fri 01 Nov 2013 08:15:41 PM UTC, comment #2:

Off the top of my head, I remember that the pkg-config files are named Qt5Gui, etc. I don't have it in front of me at the moment to check what else there was. I got around the different build flags by setting the QT_CPPFLAGS and QT_LIBS manually to get to the point I did before. I will try to recreate that build with your fix a little later today and see how far it gets me this time.

I can at least try to get a better idea of the full scope of what is needed so you can decide if this is something you want to try to address before the release. I saw this as more of a down-the-road goal, I don't know of any distros that are using Qt5 by default yet.

Mike Miller <mtmiller>
Project Administrator
Fri 01 Nov 2013 08:00:40 PM UTC, comment #1:

I fixed the include statements in this changeset:


What are the other issues? Woud you like to add them here or open separate reports about them?

John W. Eaton <jwe>
Project Administrator
Sat 12 Oct 2013 07:40:35 PM UTC, original submission:

The GUI does not compile with Qt5 currently. There are several issues ranging from include file compatibility to detecting the helper utilities and CPPFLAGS and LIBS correctly in configure.ac.

I got as far as hacking the results of configure to look at the right paths, but the changes in header files between Qt4 and Qt5 is blocking me from getting any further. The recommendations I've seen for compatibility are to not include the Qt module in #include statements, so for example use

instead of

We have quite a few of the latter variety of includes, especially in the libqterminal directory.

Mike Miller <mtmiller>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #32978:  oct-qt5.diff added by mtmiller (12KiB - text/x-patch)


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by prlw1 (Posted a comment)
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by opoplawski
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-10 dasergatskov Attached File- => Added octave_commandH_Qt5.png, #38169
    2016-08-10 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2016-08-10 jwe StatusPostponed => Ready For Test
    2016-05-02 sebald Attached File- => Added octave-config_mint_qt5-djs_2016may02.diff, #37049
    2015-04-30 opoplawski Carbon-Copy- => Added opoplawski
    2015-04-18 mtmiller Dependencies- => bugs #44874 is dependent
    2015-02-21 mtmiller StatusIn Progress => Postponed
    2015-02-03 rik5 StatusPostponed => In Progress
    2015-02-03 mtmiller Attached File- => Added oct-qt5.diff, #32978
    2013-11-02 mtmiller StatusNone => Postponed
    2013-11-02 mtmiller Severity3 - Normal => 2 - Minor

    Back to the top

    Powered by Savane 3.3