Probably due to https://bugreports.qt.io/browse/QTBUG-22829 but not helped by the fact that moc prints the wrong filename in the error (I'm seeing something similar when trying to update boost in rawhide and rebuild the packages that use it).

We currently carry,
http://pkgs.fedoraproject.org/cgit/rpms/qt.git/tree/qt-everywhere-opensource-src-4.8.6-QTBUG-22829.patch

as a workaround for currently known issues.  If you have suggestions for additions, we can do so.

Interestingly, the file name appears to be nonsense, but the line number is always 52. (Why FIFTY-two? Isn't the answer to everything FOURTY-two? ;-) )

Other packages got:
/usr/include/QtWebKit/qwebpage.h:52
and:
/usr/include/boost/predef/os/windows.h:52
as the claimed fault location.

*** Bug 1396676 has been marked as a duplicate of this bug. ***

*** Bug 1399532 has been marked as a duplicate of this bug. ***

adjusting summary

engrid is FTBFS due to this as well.

Looks like adding:

BOOST_PREDEF_VERSION_NUMBER_H

will help a lot.

Also ended up adding __G_VERSION_MACROS_H__ for the clementine build issue.  Building qt-4.8.7-22.fc26 now.

I don't see how that is anywhere near a valid fix. I think it is just a workaround that puts the bug back into latent state, and does not sustainably address it.

The only recent change in gversionmacros.h is this:
https://git.gnome.org/browse/glib/commit/glib/gversionmacros.h?id=67ce53058102905ac3c8f6f57b044616301d479b
which just adds more of the same definitions that had parsed just fine so far.

That said, the number "52" appears several times in there, which might be where the mysterious bogus "line 52" really comes from. Or it might not.

But this looks a lot like some kind of memory corruption bug in moc-qt4, possibly even a miscompilation of moc-qt4 by g++, not like anything particular in the source files being parsed (unlike the Boost issues we worked around with such #defines in the past, where we clearly identified unsupported constructs in the files we were disabling that way).

E.g., we had an error at /usr/include/QtWebKit/qwebpage.h:52, I don't think excluding qwebpage.h from moc is going to do what we want. And I think the actual file is actually completely irrelevant, given how the error always claims to be at line 52. It can probably happen in any file.

Until someone backports the fixes from qt5-moc into qt4-moc, I don't think we have much available to us other than these workarounds.  You are correct that the file name is not quite correct - it appears to be perhaps one up on the stack.  Some trial and error testing led me to the two headers that I've set to be excluded and appear to allow engrid and clementine to build.

It makes those 2 packages build, excluding a different header each time. It will not do anything to fix the packages breaking in other places.

Allowing the Boost.Predef header to be skipped will fix the build for a lot more than two packages. Most of the Boost rebuild failures I'm seeing are caused by this, and all point to a predef header. Obviously it's only a workaround not a solution, but that's still a valid fix, because the Qt team aren't going to backport the real fix to moc, and this is affecting dozens of packages in Fedora.

If you have a fix for moc please propose it, otherwise please don't be so critical of small improvements that enable other people to make progress.

There is nothing to backport from Qt 5, moc-qt5 uses a completely different parser.

And my problem with the workaround is not that it is a workaround, but that it works around symptoms, not the real source of the error, which has not been identified yet.

qmc2 seems to fail due to this as well:
http://koji.fedoraproject.org/koji/buildinfo?buildID=821821
0.69 built fine with qt-devel-1:4.8.7-19.fc26. -21 and -22 fail with
/usr/lib64/qt4/bin/moc -DQMC2_SDLMAME -DQMC2_VERSION=0.70 -DQMC2_SVN_REV=0 -DBUILD_OS_NAME=Linux -DBUILD_OS_RELEASE=4.8.11-300.fc25.x86_64 -DBUILD_MACHINE=x86_64 -DPREFIX=/usr/local -DDATADIR=/usr/local/share -DSYSCONFDIR=/etc -DQMC2_JOYSTICK=1 -DQMC2_PHONON=1 -DQMC2_MULTIMEDIA=0 -DQMC2_FADER_SPEED=500 -DQMC2_BROWSER_EXTRAS_ENABLED -DQMC2_BROWSER_PLUGINS_ENABLED -DQMC2_BROWSER_JAVA_ENABLED -DQMC2_BROWSER_JAVASCRIPT_ENABLED -DQMC2_YOUTUBE_ENABLED -DQMC2_LIBARCHIVE_ENABLED -D_REENTRANT -D_7ZIP_PPMD_SUPPORT -D_7ZIP_ST -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_PHONON_LIB -DQT_SVG_LIB -DQT_SQL_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtNetwork -I/usr/include/QtGui -I/usr/include/QtXml -I/usr/include/QtXmlPatterns -I/usr/include/QtSql -I/usr/include/QtSvg -I/usr/include/phonon -I/usr/include/QtWebKit -I/usr/include -I/usr/include/QtTest -I/usr/include/SDL2 -Ilzma -I/usr/include/minizip -I/usr/include/phonon_compat -I. -I. docbrowser.h -o moc_docbrowser.cpp
/usr/include/QtWebKit/qwebpage.h:52: Parse error at "defined"
make[1]: *** [Makefile.qmake:668: moc_docbrowser.cpp] Error 1

So we have at least /usr/include/QtWebKit/qwebpage.h and /builddir/build/BUILD/webkit-qtwebkit-23/Source/WTF/wtf/TypeTraits.h as further examples of headers that trigger this bug. There are probably more. Do you see now why I am saying that the workaround is WRONG, does not really fix anything, and does not scale?

We first need to figure out what header is ACTUALLY causing the issue and then skip THAT header, not the ones that run into trouble due to it. As long as we have not identified the actual source of the error, we are only trying (and failing) to paper over the problem.

That the headers that the workaround is trying to skip are NOT the source of the problem should also be obvious from the fact that the same headers run through moc just fine on other Fedora versions. (That is also the big difference from the Boost workaround, where the header that was skipped was actually the correct one. It is the difference between a valid workaround and broken symptom treatment.)

Fwiw, I agree with orion, this is not an either/or proposition.  Finding short-term fixes does not preclude finding any ideal long-term solutions.

/builddir/build/BUILD/kopete-16.08.3/protocols/jabber/libiris/src/irisnet/noncore/cutestuff/bytestream.h

Yet another header.

This is the header it's failing on:
https://cgit.kde.org/kopete.git/tree/protocols/jabber/libiris/src/irisnet/noncore/cutestuff/bytestream.h
I see a QT_VERSION_CHECK(5,0,0) used there too. So my theory that it might have something to do with version check macros might still hold.

Well, it chokes on boost and glib version check macros as well, so seems likely.

After adding some debugging and educated guesses, we found that *something* in rawhide was defining macros 'major' 'minor' which are both commonly used in other code (often for version checks).  We suspect glibc's sysmacros.h to be the culprit, so we're testing 2 changes:

1.  patching QT_VERSION_CHECK to use safer/namespaced variables
2.  patch moc to define _SYS_SYSMACROS_H

http://koji.fedoraproject.org/koji/buildinfo?buildID=823761

Ugh. This is because g++ auto-defines _GNU_SOURCE which makes glibc define all sorts of polluting names.

The problem is of course that moc does not implement the preprocessor correctly, the macro parameters should be shadowing the glibc macros, and also, the glibc macros are function-like macros and should thus only be expanded in a function-like context, which is not given here. But defining _SYS_SYSMACROS_H is the most effective workaround.

OK, I *think* I can confirm qt(4) is fixed, closing this.

%changelog
* Thu Dec 08 2016 Rex Dieter <rdieter> - 1:4.8.7-24
- namespace QT_VERSION_CHECK to workaround major/minor being pre-defined (#1396755)
- update QTBUG-22829.patch to define _SYS_SYSMACROS_H (#1396755)

As per IRC: Looking at the current code:
http://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/sysmacros.h;hb=HEAD
we need _SYS_SYSMACROS_H_OUTER instead of _SYS_SYSMACROS_H. _SYS_SYSMACROS_H does not actually help. Reopening.

The QT_VERSION_CHECK workaround can then also be dropped, the moc one should be sufficient on its own.

kdelibs builds fine against the current Qt 4, but that's due to the QT_VERSION_CHECK workaround, which does not help the other affected version check macros (e.g. Boost, GLib) (which is why I think you should remove that QT_VERSION_CHECK one, so that we actually test the real workaround).

(In reply to Rex Dieter from comment #26)
> OK, I *think* I can confirm qt(4) is fixed, closing this.
> 
> %changelog
> * Thu Dec 08 2016 Rex Dieter <rdieter> - 1:4.8.7-24
> - namespace QT_VERSION_CHECK to workaround major/minor being pre-defined
> (#1396755)
> - update QTBUG-22829.patch to define _SYS_SYSMACROS_H (#1396755)

That's not valid.  The name _SYS_SYSMACROS_H might change at any time.

What's odd here is that on the glibc side, we plan to remove the automatic include of <sys/sysmacros.h> in a future version, and this bug reads like major/minor is defined in *more* contexts, which is exactly the opposite of the direction we want to move in.

> That's not valid.  The name _SYS_SYSMACROS_H might change at any time.

Then we will change our moc workaround. (In fact, we should be defining _SYS_SYSMACROS_H_OUTER instead to begin with, see comment #27. Of course, that is even more likely to change at some point, but for now, it will do what we want.)

> What's odd here is that on the glibc side, we plan to remove the automatic 
> include of <sys/sysmacros.h> in a future version, and this bug reads like 
> major/minor is defined in *more* contexts, which is exactly the opposite of the 
> direction we want to move in.

I think it's actually the new, more complex CONTENTS of the definitions (with the deprecation magic) that moc chokes on.

 
qt.spec
%changelog
* Fri Dec 09 2016 Rex Dieter <rdieter> - 1:4.8.7-25
- update QTBUG-22829.patch to use _SYS_SYSMACROS_H_OUTER instead (#1396755)

(and related)
qt5-qtbase.spec
%changelog
* Fri Dec 09 2016 Rex Dieter <rdieter> - 5.7.1-8
- update moc patch to define _SYS_SYSMACROS_H_OUTER instead (#1396755)

(In reply to Kevin Kofler from comment #30)
> > That's not valid.  The name _SYS_SYSMACROS_H might change at any time.
> 
> Then we will change our moc workaround. (In fact, we should be defining
> _SYS_SYSMACROS_H_OUTER instead to begin with, see comment #27. Of course,
> that is even more likely to change at some point, but for now, it will do
> what we want.)

Oh well, I now understand there is very little alternative.

> > What's odd here is that on the glibc side, we plan to remove the automatic 
> > include of <sys/sysmacros.h> in a future version, and this bug reads like 
> > major/minor is defined in *more* contexts, which is exactly the opposite of the 
> > direction we want to move in.
> 
> I think it's actually the new, more complex CONTENTS of the definitions
> (with the deprecation magic) that moc chokes on.

Right, if moc pretends to be __GNUC__, then it must be able to handle these complex macros.

*** Bug 1401709 has been marked as a duplicate of this bug. ***

QGIS is building fine again now.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

I think all the related known issues are fixed, I'll take the liberty of closing this now.