After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 620211 - gst-plugins-base gets confused by dual-QT system
gst-plugins-base gets confused by dual-QT system
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.29
Other Linux
: Normal normal
: 0.10.30
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-06-01 05:08 UTC by nospam12
Modified: 2010-06-01 20:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description nospam12 2010-06-01 05:08:37 UTC
This is not a bug, per se, but I was asked to report it here nonetheless.

I have QT3 and QT4 installed on my system (/usr/lib/qt3 and /usr/lib/qt4). Additionally, qt4 binaries have symlinks in /usr/bin with -qt4 suffixes (e.g. /usr/bin/qmake-qt4, /usr/bin/moc-qt4, etc.) which is not an uncommon setup for dual-QT systems.

gst-plugins-base 0.10.29 picks up on my installed QT4.6+ but fails when trying to build the qtgv-xoverlay example since the moc file (moc_qtgv-xoverlay.cpp) gets generated with QT3's moc (/usr/bin/moc).

Maybe there should at least be a check that the moc used is QT4's (i.e. moc -v) to prevent compile errors down the road when it gets to qtgv-xoverlay.
Comment 1 Tim-Philipp Müller 2010-06-01 12:08:53 UTC
Thanks for the bug report. This should fix it, please re-open if it doesn't:

commit 2c21340c79717a429a2aeaf5797f9e612ddb2b9d
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Tue Jun 1 13:00:22 2010 +0100

    examples: get the right Qt moc binary to use via pkg-config
    
    Should make us do the right thing in cases where both Qt3 and Qt4
    are installed.
    
    Fixes #620211.
Comment 2 nospam12 2010-06-01 19:38:05 UTC
Just to confirm; that commit does indeed do the trick. Thanks!

P.S. I also tried it on an older machine with libtool 1.5.24 and unearthed an autogen.sh-related problem. All went well after upgrading this old machine to libtool 2.2.6b though. A snippet of the errors from the system with the older libtool after autogen.sh;make:

   make[5]: Entering directory `/tmp/gst-plugins-base-0.10.29/gst-lib/gst/interfaces'
     CC     libgstinterfaces_0.10_la-colorbalance.lo
   ../../../libtool: line 841: X--tag=CC: command not found
   ../../../libtool: line 874: libtool: ignoring unknown tag : command not found
Comment 3 Tim-Philipp Müller 2010-06-01 20:14:21 UTC
> P.S. I also tried it on an older machine with libtool 1.5.24 and unearthed an
> autogen.sh-related problem. All went well after upgrading this old machine to
> libtool 2.2.6b though. A snippet of the errors from the system with the older
> libtool after autogen.sh;make:
> 
>    make[5]: Entering directory
> `/tmp/gst-plugins-base-0.10.29/gst-lib/gst/interfaces'
>      CC     libgstinterfaces_0.10_la-colorbalance.lo
>    ../../../libtool: line 841: X--tag=CC: command not found
>    ../../../libtool: line 874: libtool: ignoring unknown tag : command not
> found

Hrm, that was a known issue when we were still using shave but I thought getting rid of shave fixed that.  Feel free to file a new bug about that.