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:
...
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
...
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
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:
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
- duplicates
-
QTBUG-63637 Cross compilation on Linux targeting MinGW is broken
- Closed