Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-133778

Core: update the port for CYGWIN

    XMLWordPrintable

Details

    • Task
    • Resolution: Unresolved
    • Not Evaluated
    • None
    • None
    • Core: Other
    • None
    • CYGWIN x86_64

    • Windows
    • 6f891f3cc (dev)

    Description

      Source code of Qt provides a basic skeleton for supporting CYGWIN and much of the needed work has been already done for other UNIX-like operating systems, since that it mimics a POSIX environment.

      Current repository for CYGWIN provides packages for supporting Qt 5.9.4 for native POSIX and both x86_64 and i686 cross compilers. Although it is not the latest version of Qt 5 officially released, it had decent support for compiling much of the software available around.

      Nowadays, several applications migrated to the newer Qt 6 libraries. For example, one of them is Musescore, which migrated to a new framework with Qt 6.2.4 as minimum requirement. Another one is Audacity 4, which uses the same framework implemented for Musescore.  Obviously, I cannot compile my versions with existing packages.

      While I expect to not find big troubles for creating up-to-date packages for MinGW-w64 cross compilers (at least, I hope so), I discovered that some changes are needed for CYGWIN, so I started to update the existing code for improving the support for this platform.

      Unfortunately, this is an inevitable step because x86_64 and i686 MinGW-w64 cross compilers are CYGWIN based and for this reason the results are exactly the same you could get on linux, for example. Infact, trying to build latest sources at the time of writing will print the following messages on the console:

      CMake Error at qtbase/cmake/QtBuildHelpers.cmake:346 (message): You need to set QT_HOST_PATH to cross compile Qt.

      So, this is the primary reason for upgrading support for CYGWIN to Qt 6 before trying to build native versions of the libraries for Windows.

      For this task, I did some patches that I shared at codereview:

      https://codereview.qt-project.org/c/qt/qtbase/+/614463?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614462?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614465?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614466?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614468?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614464?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614467?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614469?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614471?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614912?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614470?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/614941?usp=dashboard
      https://codereview.qt-project.org/c/qt/qtbase/+/628395?usp=dashboard

      Each one of these patches could be applied separately, without dependencies between them.
      There are still some open issues with CYGWIN libraries, see below, but the current set of patches already resolves the most important defects.

      At the moment, these issues are still known when compiling qtbase for CYGWIN:

      1)

      When calling executables like qdbusxml2cpp, it brutally crashes with a Segmentation Fault. For solving this issue, before start to compile I must open the generated qconfig.h and I must comment this line:

      #define QT_COMPILER_SUPPORTS_VAES 1

      Until now I haven't found other solutions: my GCC supports that, but my CPU has some troubles it seems (it's a Notebook Acer Nitro 5 with an Intel I7 11800H).
      I also tried to build on a Intel I5 7500T and on this CPU doesn't crash, so I suspect that it could be related to my hardware. However, this is strange because the code seems to be able to understand if a particular feature is supported by the host machine and it avoids its execution if it won't be able to run it.

      2)

      When the build script calls RCC, it stops because it doesn't find cygQt6Core-6.dll and it is right because the DLL is inside the /bin directory while RCC is inside /libexec. So, when the build process stops because of this error, I call "ln" command for making a link inside /libexec to this DLL and then I type "ninja" again to continue the build process until the end. Probably, this has been already resolved somewhere for MinGW, but I didn't find yet where it is.

      3)

      After the build process completes, you can install your newly compiled libraries with "ninja install", but it prints this error after a while:

      -- Starting SBOM generation in build dir: /qt-build/qtbase/qt_sbom/staging-qtbase.spdx.in
      CMake Error at qtbase/qt_sbom/SPDXRef-PackagedFile-qt-module-Core.cmake:5 (message):
        Cannot find 'lib/cygQt6Core-6.dll' to compute its checksum.  Expected to
        find it at '/opt/qt6/lib/cygQt6Core-6.dll'

      As you can see, some stuff expects to find DLLs into the /lib directory (which is the point where the .so files are located in UNIX, I think), but this is wrong because they are into the /bin directory instead. Again, I think that this case has been already handled for MinGW, but I have not found it yet.

      However, I did an experiment and I copied all Qt6 DLL files also into /lib, then I executed again "ninja install" and this time the installation process also completed successfully.

       

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            thiago Thiago Macieira
            carlo-bramini Carlo Bramini
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:

              Gerrit Reviews

                There are no open Gerrit changes