Supported architectures

[alcir]

Hello.
I was trying to package alizams on Fedora.
It compiles successfully on x86_64, while it fails on all other architectures (armv7, aarch64, ppc64le, s390x).

At a first glance, the compilation error is here:

fatal error: xmmintrin.h: No such file or directory
   34 | #include <xmmintrin.h>

Packagers more experienced than me stated that xmmintrin.h is an header for SSE CPU instructions. SSE is an x86_64 extension.
So the solution could be to "wrap" such includes with

#ifdef __SSE__
#include <xmmintrin.h>
#endif

But the point is: does alizams is supposed to work on architectures other than x86_64?

Thanks.

[issakomi]

Hello,

thank you.

I am not sure about these architectures, they are not tested, never tried, the issue with SSE may be solved with define DISABLE_SIMDMATH.

May be the line can be improved:

AlizaMS/CMakeLists.txt

Line 855 in a0cafda

if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm")

BTW, macOS Apple Silicon M1 arm64 works well, but i have done some changes to get it working.

Are arm7 and aarch64 using OpenGL or OpenGLES?

Is is possible to release only x86_64 / x86?

[alcir]

Thank you for your prompt reply.

I am not sure about these architectures, they are not tested, never tried, the issue with SSE may be solved with define DISABLE_SIMDMATH.

I will take a look.

Are arm7 and aarch64 using OpenGL or OpenGLES?

As far as I've seen in another compilation error on aarch64, by switching an "if arm" statement to OpenGL that error has gone. So I think that OpenGL is used.

Is is possible to release only x86_64 / x86?

Yes. I think that I will end up doing that. (My competencies in programming languages are very limited).

[issakomi]

Thank you very much!

Is is possible to release only x86_64 / x86?

Yes. I think that I will end up doing that.

I think it is better now. SSE2 issue is very easy to fix, but i am a little lost about Qt / OpenGL, maybe i shall buy RPi later and try.

There is another point. I have seen that Fedora uses Wayland by default, there are many problems with Qt's Wayland QPA. Debian/Ubuntu also uses Wayland by default now, but for Qt apps QtWayland is not used, only if variable QT_QPA_PLATFORM=wayland is set, by default they use xcb. On Fedora it is different, it is the reason i still release Aliza rpm only with Qt4. Qt5 build works on Fedora without problems with QT_QPA_PLATFORM=xcb, otherwise there is strange issue with transparency and many common Qt's Wayland warnings. It is safe to build with Qt4, even if AlizaMS can be build with Qt5 and Qt6. Qt4 is still available on Fedora 34. I have tried to find a workaround for transparency issue, but without success. i don't think there is a bug on my side, not 100% sure, but i use Qt5 with X11 myself many years with Debian, release Windows version with Qt5, macOS with Qt6 (to support arm64 M1 CPU). No problems, only with Qt's Wayland QPA. If you decide to use Qt4, there is also the cmake option USE_SYSTEM_GLEW_QT4, to switch between included (default) GLEW (statically linked) and distribution's GLEW (dynamically linked). For Qt5/Qt6 builds GLEW is not used at all.

Kind regards

Edit:
i have done some changes to avoid SSE2 issue, can not test, but there is also new cmake option USE_FORCE_DISABLE_SIMDMATH (off by default).

[issakomi]

Maybe i have found simple workaround to force xcb platform and avoid QtWayland issues by setting (overriding) the environment variable at the beginning of main function
setenv("QT_QPA_PLATFORM", "xcb", 1);
Seem to work, but i have to test a little to be sure.

[alcir]

Maybe i have found simple workaround to force xcb platform and avoid QtWayland issues by setting (overriding) the environment variable at the beginning of main function
setenv("QT_QPA_PLATFORM", "xcb", 1);
Seem to work, but i have to test a little to be sure.

But it is at compile time?
Because I remember that before starting an application there was an environment variable to force... Well right now I don't remember. But such variable had something to do with QT and wayland. Maybe it is this one.
And you can add it to the .desktop file.

[alcir]

I think it is better now. SSE2 issue is very easy to fix, but i am a little lost about Qt / OpenGL, maybe i shall buy RPi later and try.

Don't bother with that. Having an application that supports x86_64 only is perfectly fine.

[issakomi]

But it is at compile time?

Yes

And you can add it to the .desktop file.

Good idea, it can be Qt argument "-platform" too, the same as variable QT_QPA_PLATFORM, AFAIK. But seems to work now with setenv. Already in master branch. So Qt4 can be avoided, i hope.

[alcir]

Good idea, it can be Qt argument "-platform" too, the same as variable QT_QPA_PLATFORM, AFAIK. But seems to work now with setenv. Already in master branch. So Qt4 can be avoided, i hope.

Thanks. I will try as soon as possible.

[issakomi]

Thank you very much! Please kindly allow me several days to release next version. I am reviewing CMakeLists file and several other things. It would be really nice if there will be Fedora package. BTW, Qt6 is also possible, already works.

[alcir]

i have done some changes to avoid SSE2 issue, can not test, but there is also new cmake option USE_FORCE_DISABLE_SIMDMATH (off by default).

OK. I can confirm that now it builds successfully on armv7 and aarch64.
I need to see if the compiled program actually runs. Maybe tomorrow.

[issakomi]

OK. I can confirm that now it builds successfully on armv7 and aarch64.
I need to see if the compiled program actually runs. Maybe tomorrow.

Oh, thank you!
Interesting. I can imagine, not sure, that on arm OpenGL Core profile might work better. For Qt6 build i set Core profile (i use Qt6 only with macOS currently and macOS supports only Core profile for OpenGL 3+). For Qt5 i don't set anything explicit, it ends up in Compatibility profile (might be better for older systems), maybe i shall add a cmake option to use Core profile with Qt5 too.

[issakomi]

I have updated CMakeLists.txt, put options together for better readability, renamed several options to follow convention, they start now with ALIZA_ or MDCM_ (cmake-gui and cache file sort variables by name). MDCM_ were already correct, not changed.
Also added ALIZA_QT5_COREGL, off by default(-DALIZA_QT5_COREGL:BOOL=ON to use Core profile for Qt5 build, may be required for arm).

Highly likely there is no need to change anything, default are still applicable, if you have used force-disable SSE/SSE2 (maybe it was required, not sure), the option is named ALIZA_DISABLE_SIMDMATH now (-DALIZA_DISABLE_SIMDMATH:BOOL=ON).

If you use system libraries, they didn't change, e.g.

 -DALIZA_QT_VERSION:STRING=5 \
 -DCMAKE_SKIP_RPATH:BOOL=ON \
 -DMDCM_USE_SYSTEM_UUID:BOOL=ON \
 -DMDCM_USE_SYSTEM_ZLIB:BOOL=ON \
 -DMDCM_USE_SYSTEM_OPENJPEG:BOOL=ON \
 -DMDCM_USE_SYSTEM_CHARLS:BOOL=ON

Do you prefer system's libraries? ITK too? Statically linked included libraries and ITK work well, but may be there is policy like on Debian to prefer system's shared libraries always.

I think new release is so far ready, will look a little more at it and publish soon.

Thank you very much!

[alcir]

The compiled program works! Tested on aarch64 (Pinebook Pro).

The only issue is that the buttons are without icons. And some buttons are "invisible": the button sqare appears (without the icon) only when the mouse cursor moves on them.

[issakomi]

Thank you!

The only issue is that the buttons are without icons.

Probably something is wrong with Qt plugin iconengines/libqsvgicon.so or imageformats/libqsvg.so or Qt SVG library (libQt5Svg.so.5 or libQt6Svg.so.6)

[issakomi]

I am thinking about the issue with icons on arm. May be something is wrong with resources in general. Do you see the green logo in "About" widget? It is PNG, so if it is visible the problem is only with SVG.

Edit:
Maybe export QT_DEBUG_PLUGINS=1 could be useful.