Bug 994147 - qmake-qt5 uses Qt4 build tools
qmake-qt5 uses Qt4 build tools
Product: Fedora
Classification: Fedora
Component: mingw-qt5-qtbase (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Erik van Pienbroek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-06 11:05 EDT by holger.schletz
Modified: 2014-06-12 13:44 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-12 13:44:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description holger.schletz 2013-08-06 11:05:25 EDT
Description of problem:

When trying to compile a Qt plugin from an SRPM-generated Qt source tree, the build process stops with a compiler error. It compiles fine from a clean upstream source tree.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. yumdownloader --source mingw32-qt5-qtbase
2. rpm -i mingw-qt5-qtbase-5.1.0-1.fc19.src.rpm
3. rpmbuild -bp ~/rpmbuild/SPECS/mingw-qt5-qtbase.spec
4. cd ~/rpmbuild/BUILD/qtbase-opensource-src-5.1.0/src/plugins/sqldrivers/psql
5. /bin/i686-w64-mingw32-qmake-qt5 psql.pro
6. make

Note that I did not set INCLUDEPATH and LIBS on the qmake command line. Although necessary to compile the plugin completely, they can be omitted for this demonstration to simplify things.

Actual results:

/usr/i686-w64-mingw32/bin/moc -DUNICODE -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_XCB -DQT_NO_XKBCOMMON -DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_FROM_ASCII -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_PLUGIN -DQT_SQL_LIB -DQT_CORE_LIB -D__GNUC__ -DWIN32 -I. -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5' -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5/QtSql' -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5/QtSql/5.1.0' -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5/QtSql/5.1.0/QtSql' -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5/QtCore' -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5/QtCore/5.1.0' -I'/usr/i686-w64-mingw32/sys-root/mingw/include/qt5/QtCore/5.1.0/QtCore' -I'.moc/release-shared' -I'../../../../mkspecs/win32-g++-cross' -I/usr/i686-w64-mingw32/sys-root/mingw/include/c++ -I/usr/i686-w64-mingw32/sys-root/mingw/include/c++/i686-w64-mingw32 -I/usr/i686-w64-mingw32/sys-root/mingw/include/c++/backward -I/usr/lib64/gcc/i686-w64-mingw32/4.8.1/include -I/usr/lib64/gcc/i686-w64-mingw32/4.8.1/include-fixed -I/usr/i686-w64-mingw32/sys-root/mingw/include main.cpp -o .moc/release-shared/main.moc
usr/i686-w64-mingw32/sys-root/mingw/include/c++/bits/stl_relops.:67: Parse error at "std"

Expected results:

Should compile without errors. Without proper INCLUDEPATH and LIBS, should abort with "fatal error: libpq-fe.h: No such file or directory" or similar.

Additional info:

The generated makefile invokes /usr/i686-w64-mingw32/bin/moc, which is from Qt4, instead of moc-qt5. This example is possibly not the only way to trigger the problem.

The correct binaries are commented out in ~/rpmbuild/SOURCES/qmake.conf.win*:

#QT_TOOL.moc.binary	= i686-w64-mingw32-moc-qt5
#QT_TOOL.uic.binary	= i686-w64-mingw32-uic-qt5
#QT_TOOL.rcc.binary	= i686-w64-mingw32-rcc-qt5
#QT_TOOL.syncqt.binary	= i686-w64-mingw32-syncqt.pl-qt5

When uncommenting at least the first line (have not been hit by the others yet) before "rpmbuild -bp", a correct qmake configuration is generated in mkspecs/win32-g++-cross* and the plugin compiles successfully.
Comment 1 Erik van Pienbroek 2013-08-06 12:07:45 EDT
Why would you want to use an SRPM-generated Qt source tree in the first place? If some features are missing then it would be better to indicate this so it can be added to the regular packages. You've mentioned the PostgreSQL Qt SQL library. This one can be added normally.

The qmake.conf files which are bundled with the mingw-qt5-qtbase source rpm indeed contain some commented out lines. Initially they need to be commented out because of the fact that these tools aren't installed to their final location at this point yet and the Qt5 build system needs to use the just-build versions (which will happen automatically during normal builds of mingw-qt5-qtbase). Once mingw-qt5-qtbase is compiled these lines are un-commented as part of the %install phase in the .spec file before creating binary rpms.
Comment 2 Erik van Pienbroek 2013-08-06 12:11:26 EDT
BTW, The PostgreSQL Qt SQL module was already recently added in the rawhide branch of mingw-qt5-qtbase: http://koji.fedoraproject.org/koji/buildinfo?buildID=443133
Comment 3 holger.schletz 2013-08-06 14:54:09 EDT
Of course a regular package is a preferable solution, and having the PSQL plugin available in the latest builds is good news. However, there are many other plugins not yet packaged that still require end-user access to the source tree.

I used the SRPM tree to avoid any potential compatibility problems by building the plugin from the very same source tree than the main library, including Fedora-specific patches. I could have tried a clean upstream tree and see if it works, but the SRPM route seemed more convenient. I agree that is an uncommon use case and not what the SRPM has been designed for.

Maybe we could have the sources in a regular RPM package for the purpose of compiling plugins that are not bundled in the binary package? That would have the advantage of being upgraded automatically and keeping in sync with the binaries. The biggest problem would be setting up a shadow build for the plugins because the sources would then reside in a location read-only to regular users.
Comment 4 Erik van Pienbroek 2013-08-06 15:13:24 EDT
I still fail to see the use case here. If there are missing features/plugins then they should be reported so they can be properly packaged. The only plugin which I can think of that can't be properly packaged is the Oracle SQL plugin, but that's due to legal issues. What other features/plugins are you still missing?

The 'private' headers of Qt5 are already properly packaged so everything which other Qt5 modules/components may need should already be available.
Comment 5 holger.schletz 2013-08-07 06:14:54 EDT
If asking for a plugin means getting it, that's fine, but I think there is a reason for many plugins not being included yet.

There are legal reasons (like for the db2, oci and tds database plugins), and some plugins just aren't available or meaningful for the MinGW platform. But even without these major issues, there are additional build dependencies which are not available yet in the package archives. For example, the mingw-postgresql package required to build the psql plugin did not exist until a couple of weeks ago.

Without such packages, users in need for a certain plugin must set up the dependencies and compile the plugin manually. I'm not saying that providing the packages is impossible, and it's actually desirable, but I think there is still a long way to go. Giving the end-user easy access to the Qt sources would be an easy-to-implement interim solution that would simplify things a little.

Personally, I'm fine with the psql plugin for now. Another popular plugin that may be worth adding is the mysql driver. AFAIK, we have no mingw-mysql/mariadb package yet, so users are still required to get their hands dirty with it.
Comment 6 Yaakov Selkowitz 2014-01-02 01:04:06 EST
(In reply to holger.schletz from comment #5)
> There are legal reasons (like for the db2, oci and tds database plugins),

FreeTDS supports mingw* and can be used for the tds sqlplugin.

> Another popular plugin that may be worth adding is the mysql driver.

+1, but at least MySQL doesn't build OOTB for MinGW.
Comment 7 Erik van Pienbroek 2014-05-29 09:54:03 EDT
As of mingw-qt5-qtbase 5.2.0 (which is available in all currently supported Fedora versions) the references to tools like moc and rcc should be okay now (as they were moved to /usr/i686-w64-mingw32/bin/qt5 and the mkspecs profile hacks aren't needed any more because of this). Could you check if your original issue is resolved now so we can close this bug?
Comment 8 holger.schletz 2014-06-12 06:28:02 EDT
Using the steps in my initial report, the plugin compiles without errors now, and the correct moc version is invoked. I think this bug can be closed.

Note You need to log in before you can comment on or make changes to this bug.