[Bug]: Build fails when Qt6 GLESv2 is used because of unneeded cmake files in cmake_extras/

[ggardet]

Bug Description

Build fails on openSUSE Tumbleweed aarch64 when Qt6 GLESv2 is used because of unneeded cmake files in cmake_extras/. I needed to remove some of them:

rm cmake_extras/FindPackageHandleStandardArgs.cmake
rm cmake_extras/FindPython*.cmake

Since current cmake provides the required files.

Platform (OS)

Linux

OS Version / Specifics

openSUSE Tumbleweed aarch64

What version of Sigil are you using?

2.0.2

Any backtraces or crash reports

[   58s] -- Found GLESv2: /usr/include  
[   58s] CMake Warning at /usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:76 (find_package):
[   58s]   Found package configuration file:
[   58s] 
[   58s]     /usr/lib64/cmake/Qt6Gui/Qt6GuiConfig.cmake
[   58s] 
[   58s]   but it set Qt6Gui_FOUND to FALSE so package "Qt6Gui" is considered to be
[   58s]   NOT FOUND.  Reason given by package:
[   58s] 
[   58s]   Qt6Gui could not be found because dependency GLESv2 could not be found.
[   58s] 
[   58s]   Configuring with --debug-find-pkg=GLESv2 might reveal details why the
[   58s]   package was not found.
[   58s] 
[   58s]   Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some
[   58s]   of the path variables that find_package uses to try and find the package.
[   58s] 
[   58s] Call Stack (most recent call first):
[   58s]   /usr/lib64/cmake/Qt6/QtPublicDependencyHelpers.cmake:111 (find_dependency)
[   58s]   /usr/lib64/cmake/Qt6WebEngineCore/Qt6WebEngineCoreDependencies.cmake:39 (_qt_internal_find_qt_dependencies)
[   58s]   /usr/lib64/cmake/Qt6WebEngineCore/Qt6WebEngineCoreConfig.cmake:50 (include)
[   58s]   /usr/lib64/cmake/Qt6/Qt6Config.cmake:174 (find_package)
[   58s]   src/qt6sigil.cmake:27 (find_package)
[   58s]   src/CMakeLists.txt:685 (include)
[   58s] 
[   58s] 
[   58s] CMake Warning at /usr/lib64/cmake/Qt6/Qt6Config.cmake:174 (find_package):
[   58s]   Found package configuration file:
[   58s] 
[   58s]     /usr/lib64/cmake/Qt6WebEngineCore/Qt6WebEngineCoreConfig.cmake
[   58s] 
[   58s]   but it set Qt6WebEngineCore_FOUND to FALSE so package "Qt6WebEngineCore" is
[   58s]   considered to be NOT FOUND.  Reason given by package:
[   58s] 
[   58s]   Qt6WebEngineCore could not be found because dependency Qt6Gui could not be
[   58s]   found.
[   58s] 
[   58s]   Configuring with --debug-find-pkg=Qt6Gui might reveal details why the
[   58s]   package was not found.
[   58s] 
[   58s]   Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some
[   58s]   of the path variables that find_package uses to try and find the package.
[   58s] 
[   58s] Call Stack (most recent call first):
[   58s]   src/qt6sigil.cmake:27 (find_package)
[   58s]   src/CMakeLists.txt:685 (include)
[   58s] 
[   58s] 
[   58s] CMake Error at src/qt6sigil.cmake:27 (find_package):
[   58s]   Found package configuration file:
[   58s] 
[   58s]     /usr/lib64/cmake/Qt6/Qt6Config.cmake
[   58s] 
[   58s]   but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT
[   58s]   FOUND.  Reason given by package:
[   58s] 
[   58s]   Failed to find required Qt component "WebEngineCore".
[   58s] 
[   58s]   Expected Config file at
[   58s]   "/usr/lib64/cmake/Qt6WebEngineCore/Qt6WebEngineCoreConfig.cmake" exists
[   58s] 
[   58s] 
[   58s] 
[   58s]   Configuring with --debug-find-pkg=Qt6WebEngineCore might reveal details why
[   58s]   the package was not found.
[   58s] 
[   58s]   Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some
[   58s]   of the path variables that find_package uses to try and find the package.
[   58s] 
[   58s] Call Stack (most recent call first):
[   58s]   src/CMakeLists.txt:685 (include)
[   58s] 
[   58s] 
[   58s] -- Configuring incomplete, errors occurred!
[   58s] error: Bad exit status from /var/tmp/rpm-tmp.00LiTK (%build)

[dougmassay]

I have zero experience building anything on aarch64, let alone Sigil. However... Arch Linux seems to provide aarch64 builds of Sigil without any major patching.

So did your build work after that? The error log you posted doesn't really have any relation to the cmake_extras files you removed.

[kevinhendricks]

I can see no relation to the requested change. Your real issue is here:

58s] [ 58s] Qt6Gui could not be found because dependency GLESv2 could not be found.

It found the headers but not the lib so no gui which leads to cmake failure.

[dougmassay]

I guess it's within the realm of possibility that a newer FindPackageHandleStandardArgs that comes with the distro-supplied cmake for arm64 might find the Qt6 modules Sigil's needs. But I don't think we can rely upon all distros/archhitectures having the proper cmake_extras.

More likely, the user simply needs to provide the -DQt6_Dir location (as described in the build instructions) to properly find the Qt6 pieces needed.

[dougmassay]

I'm also unclear on what the FindPython extra has to do with the errors provided??

[ggardet]

I'm also unclear on what the FindPython extra has to do with the errors provided??

This is needed as additional fixes as I had further errors after fixing the 1st issue.

I can see no relation to the requested change. Your real issue is here:

58s] [ 58s] Qt6Gui could not be found because dependency GLESv2 could not be found.

It found the headers but not the lib so no gui which leads to cmake failure.

There is a mismatch between GLESv2 and GLESV2 in the detection. With current cmake, there is no reason to provide *.cmake overlays, especially, when they are broken. Using the ones from cmake itself just works.

https://cmake.org/cmake/help/latest/module/FindPackageHandleStandardArgs.html

[dougmassay]

But we support versions of cmake (as well as platforms) that don't always provide these extras. To say they're not needed is to say they might not be needed by you. Not everyone is using a cutting edge system like Tumbleweed or Arch.

On Mon, Feb 26, 2024, 10:19 AM ggardet @.***> wrote:

I'm also unclear on what the FindPython extra has to do with the errors provided??

This is needed as additional fixes as I had further errors after fixing the 1st issue.

I can see no relation to the requested change. Your real issue is here:

58s] [ 58s] Qt6Gui could not be found because dependency GLESv2 could not be found.

It found the headers but not the lib so no gui which leads to cmake failure.

There is a mismatch between GLESv2 and GLESV2 in the detection. With current cmake, there is no reason to provide *.cmake overlays, especially, when they are broken. Using the ones from cmake itself just works.

https://cmake.org/cmake/help/latest/module/FindPackageHandleStandardArgs.html

— Reply to this email directly, view it on GitHub https://github.com/Sigil-Ebook/Sigil/issues/740#issuecomment-1964399856, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACG3CXS452IURTZHPKXQBA3YVSRYBAVCNFSM6AAAAABD2IKUEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGM4TSOBVGY . You are receiving this because you commented.Message ID: @.***>

[dougmassay]

I'm also guessing that you could have used the -DTRY_NEWER_FINDPYTHON3=1 directive (found at the end of the Linux build instructions) when initially configuring cmake to avoid whatever errors you were getting in that regard. It doesn't use the one in cmake_extras/.

[kevinhendricks]

And that FindPython cmake I believe was specifically modified to find a suitable python within your PATH.  If that causes "issues" later on, you need to adjust your path or its order accordingly.  Not remove it as it is needed in other platforms.

The issue for you is the case difference between GLESV2 and GLESv2? Is that correct?

[kevinhendricks]

If so, and as long as the newer FindPackageHandleStandardArgs from cmake works in cmake 3.0.5 and hopefully earlier, we could pull it or case comparison related fixes from it into our internal cmake_extras build version.

Then either using the -DTRY_NEWER_FINDPYTHON3=1 or properly setting your PATH to include the version of python you actually want to build with.

[dougmassay]

I agree that removing the extra cmake files should be unnecessary. The PythonFind can definitely be overridden with configure options already. If there's a simple casing issue with GLESv2, we can fix that (unless it breaks compatibility with older versions of Qt5/CMake on certain platforms).

[kevinhendricks]

According to cmake docs, the find package command is always case sensitive on Linux. So the issue is that the headers use GLESv2 while the library itself uses GLESV2?

This sounds to me like a distribution naming issue. The real difference between our cmake_extras version and the very latest cmake version appears to be search order.

Please provide the full path on your system to the GLES version 2 headers and to the library itself. What is the exact path dependency of your qtgui lib to the GLES version2 library? Which is correct? V2 or v2?

The qtbase github repo in cmake provides the FindGLESv2.cmake file that is being used and fails to find your OpenGL library that causes the error. So v2 not V2 is correct. I really can not see how qt can not find a properly named lib.

https://github.com/qt/qtbase/blob/6bd85d4a27ba2e934fa76a430f2e1d55c08d379d/cmake/FindGLESv2.cmake

Nowhere in the provided cmake backtrace in your post are any of our cmake_extras files.

To me this looks like a improper set up, broken library naming scheme, or broken config file.

[kevinhendricks]

FWIW, I examined a more recent version of FindPackageHandleStandardArgs.cmake from cmake 3.22 and compared it against our version and there are other changes than search order. Looking at the cmake_policies they set, it appears that the newer FindPackageHandleStandardArgs.cmake should be able to replace our version as long as the underlying user is using cmake-3.3 or later.

Given we have set cmake min to cmake-3.5 in Sigil, we should be able to replace our cmake_extras/ version with one from a newer cmake release with no issues. I have tested that with macOS and no problems with the build occurred.

So as long as older Linux distributions use as least cmake-3.5 (or even 3.3) we should be okay with a change like that.

FWIW, MacOS requires the cmake_extras/ version of FindPython as the official cmake versions will not work with relocated or embedded python versions as they assume only one location for Python3 on macOS.

[kevinhendricks]

@dougmassay, Do you want me to update our version of FindPackageHandleStandardArgs.cmake to match the version in cmake-3.22? It should not impact our minimum supported cmake version to build Sigil. It may not solve his build issue but should not hurt anything either afaict.

[dougmassay]

That makes sense to me. We just moved to a 3.5 minimum in the last couple of releases. So those older distros offering older versions of Sigil should not be affected anyway.

[kevinhendricks]

Done.

@ggardet Please try a new build from master along with the -DTRY_NEWER_FINDPYTHON3=1 cmake switch and confirm if that fixes your build issues with aarch64 on Tumbleweed.

If not, please include a full set of cmake output to we can try to track down the issue further and see the exact error messages in full (including finding python).

We expect to release a new version of Sigil v2.1.0 shortly after the Easter holidays and would like to confirm if your issue is fixed.

[ggardet]

Adding https://github.com/Sigil-Ebook/Sigil/commit/12701ca7f40e90769515729717a8bf107bda22fc on top of release 2.0.2 + -DTRY_NEWER_FINDPYTHON3=1 resolves my problem. Thanks!

[kevinhendricks]

Thank you for your bug report and testing.