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

qmake generates invalid Makefile for PCRE2, failing the Qt build

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • Not Evaluated
    • None
    • 5.9.2
    • None
    • Debian Buster 64-bit, Qt 5.9.2, i686-w64-mingw32-gcc 6.3.0

    Description

      When building Windows Qt 5.9.2 on Linux with -qt-pcre, the build fails due to an invalid Makefile being generated by qmake.

      I have identified that the issue is caused by a commit made by ossi 8bebded9ab02b8eec67c44bfddf802d6bf9cda3c. This issue is present in Qt 5.9.2 but absent in Qt 5.9.1, i.e. the Makefile for PCRE2 that Qt 5.9.1 generates is valid.

      Here is the build error in Qt 5.9.2

      ...
      make -f Makefile.Release
      make[4]: Entering directory '/opt/qt5/5.9.2/build/qt-everywhere-opensource-src-5.9.2/qtbase/src/3rdparty/pcre2'
      ...
      rm -f ../../../lib/libqtpcre2.a 2>/dev/null
      .obj/release/pcre2_auto_possess.o .obj/release/pcre2_chartables.o .obj/release/pcre2_compile.o .obj/release/pcre2_config.o .obj/release/pcre2_context.o .obj/release/pcre2_dfa_match.o .obj/release/pcre2_error.o .obj/release/pcre2_find_bracket.o .obj/release/pcre2_jit_compile.o .obj/release/pcre2_maketables.o .obj/release/pcre2_match.o .obj/release/pcre2_match_data.o .obj/release/pcre2_newline.o .obj/release/pcre2_ord2utf.o .obj/release/pcre2_pattern_info.o .obj/release/pcre2_serialize.o .obj/release/pcre2_string_utils.o .obj/release/pcre2_study.o .obj/release/pcre2_substitute.o .obj/release/pcre2_substring.o .obj/release/pcre2_tables.o .obj/release/pcre2_ucd.o .obj/release/pcre2_valid_utf.o .obj/release/pcre2_xclass.o 
      make[4]: execvp: .obj/release/pcre2_auto_possess.o: Permission denied
      Makefile.Release:134: recipe for target '../../../lib/libqtpcre2.a' failed
      make[4]: *** [../../../lib/libqtpcre2.a] Error 127
      make[4]: Leaving directory '/opt/qt5/5.9.2/build/qt-everywhere-opensource-src-5.9.2/qtbase/src/3rdparty/pcre2'
      ...
      

      As you can see, it tries to run ".obj/release/pcre2_auto_possess.o" as an executable and fails with "Permission denied" error, since it can't be executed, it doesn't have the execute permission set and, well, it makes no sense to execute an object file in the first place. It tries to execute it due to the Makefile generated by qmake:

      qtbase/src/3rdparty/pcre2/Makefile.Release
      ...
      DESTDIR_TARGET = ../../../lib/libqtpcre2.a
      ...
      $(DESTDIR_TARGET):  $(OBJECTS) 
      	-$(DEL_FILE) $(DESTDIR_TARGET) 2>/dev/null
      	$(OBJECTS) 
      ...
      

      By putting "<tab>$(OBJECTS)" qmake asks make to run the object files as executables, which is a bug in qmake, it makes no sense to do that as it won't work.

      For the comparison, here is what the Qt 5.9.1, which has no such bug, does:

      ...
      make -f Makefile.Release
      make[4]: Entering directory '/opt/qt5/5.9.1/build/qt-everywhere-opensource-src-5.9.1/qtbase/src/3rdparty/pcre2'
      ...
      rm -f ../../../lib/libqtpcre2.a 2>/dev/null
      i686-w64-mingw32-ar -M < object_script.libqtpcre2.Release 
      make[4]: Leaving directory '/opt/qt5/5.9.1/build/qt-everywhere-opensource-src-5.9.1/qtbase/src/3rdparty/pcre2'
      ...
      

      Instead of trying to execute the object files, it does "i686-w64-mingw32-ar -M < object_script.libqtpcre2.Release".

      And here is the corresponding part in the Makefile

      qtbase/src/3rdparty/pcre2/Makefile.Release
      ...
      DESTDIR_TARGET = ../../../lib/libqtpcre2.a
      ...
      $(DESTDIR_TARGET):  $(OBJECTS) 
      	-$(DEL_FILE) $(DESTDIR_TARGET) 2>/dev/null
      	i686-w64-mingw32-ar -M < object_script.libqtpcre2.Release 
      ...
      

      It puts "i686-w64-mingw32-ar -M < object_script.libqtpcre2.Release" on that line, instead of "$(OBJECTS)".

      This change in behavior is caused by 8bebded9ab02b8eec67c44bfddf802d6bf9cda3c commit. It appears like the

      qtbase/mkspecs/win32-g++/qmake.conf
      equals(QMAKE_HOST.os, Windows) {
          QMAKE_LINK_OBJECT_MAX = 10
          QMAKE_LINK_OBJECT_SCRIPT = object_script
      }
      

      part is causing qmake to not use object_script on Linux host.

      Now, I know that Qt project doesn't officially support building Windows Qt on Linux, or on anything else but Windows, but as an open source developer, I'd like to avoid having Windows OS installed if I can get away with building it on Linux, and I think many other OSS developers would share the same sentiment, so I ask kindly to fix this bug.

      For anyone having the same issue, here is a workaround I used to get Windows Qt 5.9.2 to build on Linux:

      patch.sh
      echo "QMAKE_LINK_OBJECT_MAX = 10" >> qtbase/mkspecs/win32-g++/qmake.conf
      echo "QMAKE_LINK_OBJECT_SCRIPT = object_script" >> qtbase/mkspecs/win32-g++/qmake.conf
      

      It just makes the body of the equals-condition being evaluated unconditionally.

      Attachments

        Issue Links

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

          Activity

            People

              buddenha Oswald Buddenhagen
              nurupo nurupo
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes