Qucs from AppVeyor has severe graphics issues

Qucs / qucs

Qucs Project official mirror

http://qucs.sourceforge.net/

GNU General Public License v2.0

1.15k stars 212 forks source link

Qucs from AppVeyor has severe graphics issues #958

Open in3otd opened 4 years ago

in3otd commented 4 years ago

see here.

Since fixing the Appveyor build both the 32 b and the 64 b builds have issues with the schematic graphic. I've compared the AppVeyor latest build log with the one from 7 months ago (last successful before removal of Qt4 package from MSYS2) and didn't see any significant difference. The old artifact is no longer available, unfortunately.

in3otd commented 4 years ago

I've done some experiment but still it's not clear where this issue comes from:

the 32 b and 64 b versions from AppVeyor always shows this issue
compiling the latest sources in Windows locally (with an MSYS2 install of a couple of years ago), everything works fine
overwriting qucs.exe of a local build with one from AppVeyor shows the issue, so I think this is not due to any new/different libraries version

Vort commented 4 years ago

It looks like problem comes from Qt: foreach is broken. https://forum.qt.io/topic/105934/q_foreach-no-longer-works-as-intended

Vort commented 4 years ago

GCC 9 miscompiles Qt4 "foreach" macro

in3otd commented 4 years ago

uh, thanks! - apparently my google-fu was weak.

Vort commented 4 years ago

Determining the reasons for crashes (null pointer dereference in this case) is not so hard usually. Another question - is what to do next. I will try next version of GCC (9.2.0 -> 9.3.0), but not sure if it will help.

Vort commented 4 years ago

Patching of the Q_FOREACH macro inside the following files fixes the problem: \msys64\mingw64\include\qt4\Qt\qglobal.h \msys64\mingw64\include\qt4\QtCore\qglobal.h https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b (I have patched both of them just in case)

But I completely don't know how to integrate such fix into build system.

felix-salfelder commented 4 years ago

On Wed, Apr 08, 2020 at 08:23:50AM -0700, Vort wrote:

But I completely don't know how to integrate such fix into build system.

Write a test against the condition. Integrate it with configure. Error out if the problem exist. I.e. simply don't build anything.

Your test will pass, as soon as they have fixed the problem (I expect they will). The test should also pass with gcc-8, so use that in the meantime.

(If it's not worth the trouble: list the broken compiler/qt version number combination in the list of (un)supported compilers.)

Vort commented 4 years ago

Your test will pass, as soon as they have fixed the problem

Looks like this will never happen. Both from GCC and Qt sides.

So I see 3 options:

Upgrade to Qt5.
Fix Qt4 manually.
Use old GCC version.

It is also possible to switch to Clang, but they can also copy GCC behaviour eventually.

felix-salfelder commented 4 years ago

On Wed, Apr 08, 2020 at 09:27:16AM -0700, Vort wrote:

Your test will pass, as soon as they have fixed the problem

Looks like this will never happen. Both from GCC and Qt sides.

So I see 3 options:

Upgrade to Qt5.

Fix Qt4 manually.

Use old GCC version.

It is also possible to switch to Clang, but they can also copy GCC behaviour eventually.

If this happens, then I would even more expect that they will fix qt4. Note the multiple possible values of "they" here.

I like 3 best, especially because of 1 (Where your time is better spent). If you fancy 2, try this:

find a way to detect if the problem exists.
add a directory "contrib/include" to the repo, containing fixed header(s).
pass -I${top_build_dir}/contrib/include to the preprocessor as needed.

Nested include statements within Qt might be a pain. Watch your step.

in3otd commented 4 years ago

IMHO, you can simply put a patch in contrib and apply it as done for ASCO.