Qucs from AppVeyor has severe graphics issues

[in3otd]

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]

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]

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

[Vort]

GCC 9 miscompiles Qt4 "foreach" macro

[in3otd]

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

[Vort]

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]

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
qt/qtbase@c35a3f5 (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]

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]

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:

1. Upgrade to Qt5.
2. Fix Qt4 manually.
3. Use old GCC version.

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

[felix-salfelder]

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: 1. Upgrade to Qt5. 2. Fix Qt4 manually. 3. 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]

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