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): 5.1.0-1.fc19 How reproducible: always 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.
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.
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
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.
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.
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.
(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.
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?
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.