Sigil crashes with fatal OpenGL error

[DiapDealer]

You would only see anything about Qt in the cmake configure output if things couldn't be found. Otherwise, I agree: there's something up with the system qt build/configuration if that command I gave you doesn't result in the actual directory where the Qt libraries are.

[Banjo]

I am putting together a new installation of Mageia on another computer.... this one actually that I am now running Mint on.... but is has stalled because of other issues.

When I get back to it, I will install sigil and see if the problem arises on this platform. If it does, I will post a bug to the packager and he can look at it and maybe boost it upstream.

[KevinH]

FWIW, On macOS, Qt depends on knowing where it was compiled and built. It stores that info and will reguritate it as one of its paths and even uses it in macdeployqt. This is why on travis we need to use symlinks to get the Qt build to work with the Sigil build. So if qmake uses that compiled in home location but someone moved it into aQt5 subdir later (without a build), Qt would react the way you are seeing.

[DiapDealer]

That would certainly qualify as a mistake in a repo-supplied version of qt5, I think. If they needed to move it after compilation, they should at least be able to provide a qt.conf file to make sure that the qmake -query functionality reports accurate locations.

I use qmake -query to determine the installed locations of the qt libs/plugins/translations on Linux and Windows Sigil builds (Linux primarily for configuring the launch script in question), and this is the first time anyone has reported a failure of this kind with a repo-installed version of qt5 on Linux.

[DiapDealer]

Originally Posted by KevinH

This is why on travis we need to use symlinks to get the Qt build to work with the Sigil build.

Not that it's much of a hindrance for travis builds, but I've been wondering if a qt.conf file might be able to be used to avoid needing to copy the plugins folder to the hard-coded installation path where macdeployqt expects them to be. Curious more than anything, since the current travis builds seem to work fine (and there doesn't seem to be any adverse runtime consequences).

[DiapDealer]

In all fairness: if utilizing the default system qt5 on Linux (like all repo versions of Sigil will), there's really no need to add the QT_INSTALL_LIBS location to the LD_LIBRARY_PATH via the Sigil launch script (though as long as it's correct, it hurts nothing). Perhaps I should look into providing a USING_SYS_QT5 cmake directive that packagers/builders could use to configure the launch script to skip that part.

[Banjo]

I contacted the folks at Mageia to see if anybody could duplicate this problem on their system. The answer was that the repository version of Sigil runs just fine out of the box. So I am thinking that there is something messed up on my system that is causing the confusion.

It is interesting that the other Mageia user said that Sigil was pointing to /usr/lib64, and that Qt has been down in /usr/lib64/qt5 for quite some time now. That is its normal place now.

So the puzzle for me now is how it runs on his system.

I am going to fool around with it some more to see if I can figure out what is going on, but there appears to be no problem on the Mageia 7 clean install. We can call off the dogs.

[DiapDealer]

Perhaps there's some sort of misconfiguration of the "alternatives" program? Some systems use something similar to handle multiple versions of installed programs (or multiple utilities that perform the same task). It typically handles creating the proper shortcuts to the various alternative versions.

See if the following command produces any relevant results:

update-alternatives --config qt5

[Banjo]

I put the /usr/bin/sigil script back to its original state so that the program will crash again. Then I ran the update-alternatives command and it appeared to do nothing at all. It just returned to a prompt. Sigil continued to crash after that. What should i see from that command?

I tried adding /usr/lib64/qt5 to LD_LIBRARY_PATH and that did not help.

I don't know how it could be running on that other fellow's computer since outwardly he has the same situation as I do WRT the Qt libraries.

I had to turn it off for tonight. Maybe I will look at it again tomorrow.

[DiapDealer]

Qt may not be set up in the alternatives database. That could be part of the issue.

[Banjo]

I booted my Mageia computer and confirmed that Sigil still crashes when using the original script. OK fine.

I renamed the superfluous Qt folders in /usr/lib64, qt3 and qt4, to remove them from any search in /usr/lib64. That had no effect, and Sigil crashed anyway. So I put them back.

Then, I edited the /usr/bin/sigil startup script and commented out the QTLIB_DIR environment variable

#QTLIB_DIR="/usr/lib64"

After that, Sigill runs fine. I presume that without the QTLIB_DIR variable, Sigil defaults somehow to a system default for Qt. How does a program find a system default? Is there a prescribed search sequence?

Anyway, another workaround for this problem is to simply remove the environment variable from the script.

I found /etc/alternatives and listed anything with qt

[root@BSKMageia alternatives]# ll | grep qt
lrwxrwxrwx 1 root root 36 Jul 22  2019 bssh-askpass -> /usr/libexec/openssh/qt5-ssh-askpass*
lrwxrwxrwx 1 root root 24 Feb 17 07:53 qmake -> /usr/lib64/qt5/bin/qmake*
lrwxrwxrwx 1 root root 25 Apr 18  2019 qtconfig -> /usr/lib/qt3/bin/qtconfig*
lrwxrwxrwx 1 root root 36 Jul 22  2019 ssh-askpass -> /usr/libexec/openssh/qt5-ssh-askpass*

It is interesting to note that qtconfig is pointing to qt3/qtconfig. That doesn't sound right.

But there is no qtconfig in qt5, so maybe qtconfig is something that is not used anymore.

Continuing to look for what is going on here.

[DiapDealer]

I'd say something got messed up with your qt5 environment somehow.

As long as it's reported as working on clean Mageia installations, I don't think I'll worry about making any changes to Sigil's build/install process. Though I may add something to the wiki about linux crashes and the launch script for future reference. Still seems a bit odd to me that a QSurface error is what's causing a crash on first launching Sigil when the qt libs can't be found. I would normally expect a platform plugin error under those conditions. *shrug*

[Banjo]

I agree. At some point I will flash my computer back to a clean installation and start over and the whole issue will go away.