Bug 756395 - [Boost-1.48.0] Qt and [Parse error at "BOOST_JOIN"] error
[Boost-1.48.0] Qt and [Parse error at "BOOST_JOIN"] error
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: 754865
  Show dependency treegraph
Reported: 2011-11-23 07:50 EST by Denis Arnaud
Modified: 2013-10-04 08:31 EDT (History)
14 users (show)

See Also:
Fixed In Version: qt-4.8.0-0.27.rc1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-12-03 20:58:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Workaround (2.33 KB, patch)
2011-11-30 06:37 EST, Petr Machata
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Qt Bug Tracker QTBUG-22829 None None None Never

  None (edit)
Description Denis Arnaud 2011-11-23 07:50:45 EST
Description of problem:
Duplication of an external bug, opened against Qt at Nokia: https://bugreports.qt.nokia.com/browse/QTBUG-22829

Version-Release number of selected component (if applicable):
* Boost-1.48.0-1
* Qt-4.{6,7}

The problem does not show up with Boost-1.47.

How reproducible:

Steps to Reproduce:
1. Compile Qt-4.{6,7} with Boost-1.48 on Rawhide
Actual results:
There are multiple compilation errors, such as "Parse error at "BOOST_JOIN", pointing to boost/type_traits/detail/has_binary_operator.hp

Expected results:

Additional info:
It seems the bug is more on the Qt MOC compiler side, as discussed in the Boost mailing lists:
Following are the links to the discussion:
* http://groups.google.com/group/boost-list/browse_thread/thread/212fa3fa2f712206
* http://groups.google.com/group/boost-list/browse_thread/thread/1642b52217e30ff7/313695d3024a0234?show_docid=313695d3024a0234

However, a Boost-related workaround could maybe found (as the issue appeared only from Boost-1.48).
Comment 1 Jan Kaluža 2011-11-24 05:14:08 EST
If you want to test some fixes or workarounds, you can scratch-build my "swift" package which currently doesn't build in rawhide because of this Qt bug.

Here's the build.log: http://koji.fedoraproject.org/koji/getfile?taskID=3531816&name=build.log
Comment 2 Petr Machata 2011-11-30 06:37:00 EST
Created attachment 538531 [details]

Looking into this.  The problematic part is this line in header boost/type_traits/detail/has_binary_operator.hpp:
> namespace BOOST_JOIN(BOOST_TT_TRAIT_NAME,_impl) {

The trouble is, this header is included several times with differing values of BOOST_TT_TRAIT_NAME, so we can't pre-expand it simply.  But I don't suppose the datum is important in any way to the MOC parser, so in the patch, I just make the whole block invisible to MOC.
Comment 3 Petr Machata 2011-11-30 06:39:36 EST
But this is in fact a bug in MOC.  The code is correct on boost side.  I'm reassigning this to Qt in hope you guys can patch around this problem yourself.  But if it's somehow a problem, let me know, and I'll turn in the workaround that I attached above.
Comment 4 Petr Machata 2011-11-30 06:41:46 EST
Here, have this nice reproducer:

#define X(A) A
#define Y a
namespace X(Y) {
  class meh {};

$ g++ -c ble.cc
$ moc-qt4 ble.cc
ble.cc:3: Parse error at "X"
Comment 5 Rex Dieter 2011-11-30 07:53:14 EST
Per the upstream bug, an alternative workaround includes:

"Passing the following to moc will prevent it from parsing through the portion of boost that it is having problems with:
Comment 6 Petr Machata 2011-11-30 09:03:33 EST
Thanks, that's a nice idea.  Jan, does that seem like an acceptable workaround to you?  That would hide from MOC the whole boost/type_traits/has_operator.hpp that drags in the problematic headers.  That would be preferred from my point of view--if we are introducing a kludge, let's do it in the least exposed place.
Comment 7 Kevin Kofler 2011-11-30 10:38:20 EST
A quick hack might be to predefine that macro in MOC, at the same place where QT_MOC_RUN is being predefined at.

The problem is that MOC's C++ parser is quite dumb, it only parses a subset of C++, ignores everything else, and occasionally chokes on something. AFAIK, it doesn't actually do preprocessor expansion at all (and in fact that's sometimes a way to sneak unsupported constructs past MOC, e.g.
"#define foo foo __attribute__((unused))").
Comment 8 Kevin Kofler 2011-11-30 10:40:15 EST
(To clarify my example: MOC will normally just ignore function prototypes and variable declarations entirely, and thus not choke on that attribute, but if you want to put an __attribute__((unused)) on a parameter is a Qt slot, it at least used to not like it.)
Comment 9 Jan Kaluža 2011-12-01 06:19:39 EST
I've tested building swift with "moc-qt4 -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED" and it worked properly. I will use this workaround for now to get rid of those "Broken dependencies" emails.
Comment 10 Kevin Kofler 2011-12-03 17:23:19 EST
IMHO, littering all packages with this workaround is a very bad idea.

I'm looking into patching MOC to predefine that symbol.
Comment 11 Kevin Kofler 2011-12-03 18:34:06 EST
I added this patch:
to qt-4.8.0-0.27.rc1.fc17, which is now building in Rawhide. I can also add the same workaround to qt3.
Comment 12 Kevin Kofler 2011-12-03 20:58:37 EST
This is now fixed in Rawhide with my 1-line workaround, I'll leave it to the upstreams to come up with a cleaner fix.
Comment 13 Kevin Kofler 2011-12-03 21:08:27 EST
As for qt3, its MOC had a different parser, so I'm only going to patch things if we know it's also affected.
Comment 14 Red Hat Bugzilla 2013-10-03 20:22:10 EDT
Removing external tracker bug with the id '22829' as it is not valid for this tracker

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