Confirmed. Some debug information:

line 129 reads:

return (GST_CAPS_REFCOUNT_VALUE(object<GstCaps>()) == 1);

and GST_CAPS_REFCOUNT_VALUE is actually:

#define GST_CAPS_REFCOUNT_VALUE(caps) \
 (g_atomic_int_get (&(GST_CAPS(caps))->refcount))

The problem relies on the implementation of g_atomic_int_get. In glib 2.28, it is defined as:

# define g_atomic_int_get(atomic) \
 ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gint) ? 1 : -1]), \
  (g_atomic_int_get) ((volatile gint G_GNUC_MAY_ALIAS *) (volatile void *) (atomic)))

...which works (despite being unreadable :P).
However, in glib 2.29 it is defined as:

#define g_atomic_int_get(atomic) \
  (G_GNUC_EXTENSION ({                                    \
    G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gint));  \
    (void) (0 ? *(atomic) ^ *(atomic) : 0);               \
    __sync_synchronize ();                                \
    (gint) *(atomic);                                     \
  }))

which fails if "atomic" is a call to a C++ member function.
The bug actually appears in G_STATIC_ASSERT, which is defined as:

#define G_STATIC_ASSERT(expr) typedef struct { char Compile_Time_Assertion[(expr) ? 1 : -1]; } G_PASTE (_GStaticAssert_, __LINE__)

A quick test reveals that the following fails to compile:

typedef struct {
  char Compile_Time_Assertion[
     (sizeof(object<GstCaps>()->refcount) == sizeof(gint)) ? 1 : -1
  ];
} Foobar;

...while this one works fine:

typedef struct {
  char Compile_Time_Assertion[
     (sizeof(this->object<GstCaps>()->refcount) == sizeof(gint)) ? 1 : -1
  ];
} Foobar;

Imho, this is a compiler bug. An explicit use of the "this" pointer should not be required in the context of a member function.

Here comment added by gcc maintainer:
https://bugzilla.redhat.com/show_bug.cgi?id=716209#c8

If you think this is a compiler bug, you'd need to provide self-contained
(preferrably small, see http://gcc.gnu.org/bugs/ for details how to submit
proper bugreports) testcase, the comment in gnome bugzilla has nothing like
that.
And the claim that this-> should never be needed in C++ in the context of a
member function is obviously false, e.g. in templates with dependent bases
added this-> makes names dependent where they were previously non-dependent and
so is needed in order to access members of the dependent bases.

Hi, is there any news about fixing this bug?

It should be now fixed (worked around) in master, but I haven't tested it.

Alexey, could you try git master to see if this fixes the issue for you?

http://cgit.freedesktop.org/gstreamer/qt-gstreamer/commit/?id=a5487083433341783733858b5c153b759053f032

This patch fixes qt-gstreamer build for Fedora 16 with glib 2.29.16.