| Summary: | moc-qt5 issues with QT_VERSION macros | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christian Dersch <lupinix.fedora> |
| Component: | qt5-qtbase | Assignee: | Than Ngo <than> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | evan.teran, jgrulich, jreznik, rdieter, than, umar |
| Target Milestone: | --- | Keywords: | Tracking |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qt5-qtbase-5.7.0-5.fc25, qt5-qtbase-5.7.1-9.fc26 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-07-18 15:55:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 1386665, 1394562 | ||
| Bug Blocks: | |||
|
Description
Christian Dersch
2016-12-13 15:43:18 UTC
This issue has been fixed in qt5-qtbase-5.7.0-5.fc25, but rebuilds of depending packages *may* be required in cases where affected moc-qt5 was used @build time. FYI, this issue was fixed in the following versions: f26: qt5-qtbase-5.7.1-9.fc26 f25: qt5-qtbase-5.7.0-5.fc25 so anything built with those (or newer) should be better. I see that there is a one line difference between qtbase-opensource-src-5.7.1-moc_macros.patch and qtbase-opensource-src-5.6.0-moc_WORDSIZE.patch for 5.7.0 namely, pp.macros["_SYS_SYSMACROS_H_OUTER"]; line. Also, qtbase-opensource-src-5.7.1-QT_VERSION_CHECK.patch is not in 5.7.0 but it applies correctly. Any harm in using these in 5.7.0? The QT_VERSION_CHECK.patch and _SYS_SYSMACDROS_H_OUTER definition was a different approach to fixing similar symptoms. Ended up they didn't help much. Sorry, to be more specific than "didn't help much": They did help... some. They were workarounds for specific similar symptoms, but didn't fix the root cause. Thanks....I see that we are moving to 5.7.1 in fc25. What is the best way to test if this patch is present on my system? I believe I am running into this issue on a FC25 system with qt5-qtbase-5.7.1-14.fc25.x86_64 My symptoms are that for a specific piece of code (unfortunately other similar code seems to work OK), QT_VERSION appears to have a value of 0 at MOC time. I tested this via trial and error while manually invoking /usr/lib64/qt5/bin/moc. Thanks Things should be fixed since qt5-qtbase-5.7.1-6, but it's possible your code is hitting a different (but similar bug). Yea, last night I was able to avoid the bug. My code indirectly includes <QObject> and <QtGlobal>, which should be more than enough to get a working QT_VERSION macro, and indeed things compile and work on my Gentoo, and Ubuntu setups. But on FC25 it would compile just fine (meaning the macro was defined), but the plugin metadata object just wasn't getting emitted. I narrowed it down to QT_VERSION being set, but having a value of 0 (as mentioned in my comment). And since my code is for both Qt4 and Qt5, I have some plugin related stuff in #ifdef's testing the QT_VERSION. So, it seems that moc is doing a much less robust job of preprocessing the code than a proper compiler. Simply adding an explicit <QtGlobal> include as the first include in the plugin's header makes it work properly. I don't know why moc on FC is acting slightly differently than other distributions. Perhaps slightly different approaches to patching this type of issue? Either way, I was able to (I think) work around the issue. We'll see if I get any new bug reports :-) Thanks anyway. i cannot reproduce this issue in f25/f26 release. The patch for this issue was applied correctly. Feel free to reopen it if someone can reproduce it. Thanks |