How can i install PyQt with Phonon included?

[handsomegui]

After i installed PyQt4 by:

brew update
brew install pyqt

Homebrew installed me a PyQt at version 4.10.2, but with no Phonon module compiled.
When i run some app that required Phonon, it reports:

"Your Qt installation does not have Phonon support."

I have tried: brew search phonon with no results.
How can i fix this by homebrew?

My installation is on Mac OS X 10.8.4 with brew-installed Python 2.7.5.

[samueljohn]

We don't explicitly disable it. I have that module but when trying to import I get an error:

import PyQt4.phonon

ImportError: dlopen(/homebrew/lib/python2.7/site-packages/PyQt4/phonon.so, 2): Symbol not found: __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE0EE11qt_metacastEPKc
  Referenced from: /homebrew/lib/python2.7/site-packages/PyQt4/phonon.so
  Expected in: dynamic lookup

[samueljohn]

I am not sure if this an upstream or homebrew issue...

[mistydemeo]

Homebrew doesn't have a phonon formula (it's one of the orphaned kde formulae), so presumably phonon.so does nothing if it doesn't have a real phonon library to link against.

[samueljohn]

@mistydemeo but there is Cellar/qt/4.8.5/lib/phonon.framework .. so I thought Qt shipped that.

[MikeMcQuaid]

There's two versions of Phonon; the one included in Qt and the one included with KDE (which is newer). Sometimes stuff looks for the latter and when it fails to find it complains it can't find anything. That'll be what's happening here.

[samueljohn]

But PyQt4.phonon should look for the Phonon that comes with Qt, right?
I have no clue how to fix this ...

[MikeMcQuaid]

Perhaps not, they might want a newer version.

[peterbrook]

For reference, I've been hitting this same issue with PySide. brew install pyside gives me a working pyside installation, except the phonon module error. I'm not sure what the best way to debug the error further is.

I was able to make "import PySide.phonon" work on my mac by installing pyside and qt binaries from http://qt-project.org/wiki/PySide_Binaries_MacOSX but this is obviously not ideal (old versions, not managed by homebrew, etc).

[samueljohn]

Anyone good at Qt/phonon/pyside/pyqt knowing what to do here?

[MikeMcQuaid]

I'm good at Qt/Phonon and the problem is either looking in the wrong place or having too old a version of Phonon for it to be handled properly.

Can someone try and reproduce this building from source themselves? I suspect this is an upstream issue.

[handsomegui]

Did you mean that grabbing the latest version of Phonon source code from KDE then build/compile it on OS X manually?

[peterbrook]

If you want to go this route, it looks like kde-phonon is available by tapping tomahawk-player. see the instructions at http://wiki.tomahawk-player.org/index.php/Building_OS_X_Application_Bundle

[handsomegui]

I followed the wiki page of Tomahawk, still no luck :(
As below:

brew tap tomahawk-player/tomahawk

brew install --HEAD vlc
brew install phonon-vlc

## Updating Qt:
cd /usr/local
brew cleanup
packages_using_qt=`brew uses --installed qt`
echo $packages_using_qt | xargs brew remove
echo $packages_using_qt | xargs brew install
unset packages_using_qt

[handsomegui]

From the past experience of using Macports.
I didn't recall there is problem for the phonon thing. (By: port install py27-pyqt)

So, is there any workaround for this phonon thing on top of homebrew?

[samueljohn]

I can very distantly remember that I once ran a sample python code that was using phonon to play some sound. And I did it with the brewed version. So perhaps some recent Qt/PyQt issue?

[MikeMcQuaid]

@handsomegui @peterbrook That means taking the Qt tarball Homebrew uses and building and installing it into the same location with the same options as Homebrew and seeing if the bug is still there. If so: upstream issue.

[grosch]

Any progress here? I'm seeing the exact same missing symbol. Who rebuilds the package that brew uses so that we get the right "stuff"

[samueljohn]

@grosch as said, we didn't change anything or disable it, therefore Qt seems to have disabled or removed phonon. I think nobody had the time to do the "manual" build Mike was suggesting.

[peterbrook]

I have a bit of time, so I'm going to try to investigate this. First off I just verified that "brew install python pyside" followed by python -c "from PySide import phonon" generates the above error on a brand new OSX install running in virtualbox.

Next I'll do the manual qt install and see if the error's there, and if so I'll try to figure out how the working pyside binaries that are available for download were created.

[samueljohn]

👍 for doing this @peterbrook. Let us know if you can find a satisfying solution.

[sclaes]

When trying to import PyQt4.phonon I get a slightly different error:

ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/PyQt4/phonon.so, 2): no suitable image found. Did find:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/PyQt4/phonon.so: mach-o, but wrong architecture

Can I just remove this version and try to install phonon with either
pip phonon
or
brew install phonon ?

Any comments? TIA

[daviewales]

MacPorts has a patch related to this. I don't know if it is relevant here.

[adamv]

I don't want to shut down the conversation here, but is there any chance of this turning into a pull request soon?

[daviewales]

I've had a look into it a couple of times since, but I haven't found a solution yet. I will probably have another good look at it this July in my uni holidays.

In short, it may yet turn into a pull request, but probably not soon.

[testinfected]

I have been using phonon with Qt 4.8.5 and PyQt4 just fine since last summer until a few days ago when I attempted the upgrade to 4.8.6. Now I get the same error @samueljohn is getting, i.e.:

import PyQt4.phonon

ImportError: dlopen(/homebrew/lib/python2.7/site-packages/PyQt4/phonon.so, 2): Symbol not found: __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE0EE11qt_metacastEPKc
  Referenced from: /homebrew/lib/python2.7/site-packages/PyQt4/phonon.so
  Expected in: dynamic lookup

If that helps, I managed to get a working setup of Qt 4.8.6, PyQt 4.10.4 and Phonon using MacPorts.

[daviewales]

That is very interesting. I've had a quick look at the MacPorts PyQt port file. They have kde-phonon as a dependency. e.g. They don't use the phonon included with Qt. (unlike Homebrew)

[daviewales]

My current feeling is that we would need to do the following to get this to work:

1. Install qt with these configure flags: -no-phonon, -no-phonon-backend
2. Install kde-phonon
3. Install pyqt (may need to add kde-phonon as a dependency in pyqt so it can find the libraries.)

I'm currently testing this theory, but compiling takes a long time...

[daviewales]

kde-phonon is from hombrew-kde tap. If it turns out we need it, should it be promoted to main homebrew?

[MikeMcQuaid]

Maybe, yeh. Would be better to keep it :optional for a while first.

[daviewales]

Thanks. I'm having a look at the diff now. If it works, it will give us something to go on.

[testinfected]

I've reinstalled qt 4-8.5, built from source, sip and pyqt 4.10.3 using the new formulae. And I get exactly the same error:

ImportError: dlopen(/homebrew/lib/python2.7/site-packages/PyQt4/phonon.so, 2): Symbol not found: __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE0EE11qt_metacastEPKc
  Referenced from: /homebrew/lib/python2.7/site-packages/PyQt4/phonon.so
  Expected in: dynamic lookup

I don't understand why this is happening. It was working before. The difference is that I used new versions of the formulae (changing the download link) and probably I'm using a newer Xcode (5.1.1). I can't remember what version of XCode I was using last summer when I originally built pyqt, probably 4.x?

[mistydemeo]

Can you check, from otool -L, that both qt 4.8.5 and the phonon module are linked against the same C++ standard library?

[testinfected]

Both .so and frameworks are linked against /usr/lib/libstdc++.6.dylib on my machine (10.8).

What specific files should I check?

[mistydemeo]

How about /homebrew/lib/python2.7/site-packages/PyQt4/phonon.so? They're all using the same stdlib?

[testinfected]

Yes. I checked phonon.so and the other pyqt so files. Same stdlib as the Qt frameworks.

otool -L lib/python2.7/site-packages/PyQt4/phonon.so
lib/python2.7/site-packages/PyQt4/phonon.so:
    /usr/local/opt/pyqt/lib/python2.7/site-packages/PyQt4/libphonon.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/phonon.framework/Versions/4/phonon (compatibility version 4.4.0, current version 4.4.0)
    /usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.5)
    /usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.5)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)

[daviewales]

I'm afraid I'm going to have to leave this unsolved for now, as I have uni exams and assignments to do. I'll have another go at it in the holidays. Anyone else is welcome to try, however. For future reference, here is what I am currently stuck on:

The facts:

• Qt Phonon works with C, C++ programs.
• Qt Phonon does not work with PyQt.
• PyQt can see Qt phonon, but we get the above errors when we try to use it.
• Qt Phonon is a framework.

What I've tried:

• Installing KDE Phonon.
  • PyQt can't see KDE Phonon, because it expects to find it in the Qt directory. (This is not just because KDE Phonon is keg-only, because I tried making it a regular build, and PyQt still couldn't see it.
• Running install_name_tool on the Python site package to change Phonon libs.
  • This doesn't work.
• Creating a framework from the KDE libs
  • I probably did it wrong, but I couldn't get this to work.
• Symlinking various things at random.
  • Didn't work (unsurprisingly!)

What I haven't tried:

• Editing the PyQt configure script to point to non-framework KDE Phonon.
• Editing the PyQt configure script at all.
• Copying all the files from the KDE Phonon into the Qt Phonon framework, to see if it fixes it. (e.g. to see if the problem is with Qt Phonon itself, or just some weird PyQt configure bug.)
• Something more sophisticated that I haven't thought of yet.

[testinfected]

Is it ok that phonon.so is linked against /usr/local/opt/pyqt/lib/python2.7/site-packages/PyQt4/libphonon.dylib which does not exist?

otool -L lib/python2.7/site-packages/PyQt4/phonon.so
lib/python2.7/site-packages/PyQt4/phonon.so:
    /usr/local/opt/pyqt/lib/python2.7/site-packages/PyQt4/libphonon.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/phonon.framework/Versions/4/phonon (compatibility version 4.4.0, current version 4.4.0)
    /usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.5)
    /usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.5)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)

It might not be an issue, since it's the same for QtCore:

otool -L /usr/local/lib/python2.7/site-packages/PyQt4/QtCore.so
/usr/local/lib/python2.7/site-packages/PyQt4/QtCore.so:
    /usr/local/opt/pyqt/lib/python2.7/site-packages/PyQt4/libQtCore.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.5)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)

and /usr/local/opt/pyqt/lib/python2.7/site-packages/PyQt4/libQtGui.dylib does not exist either.

[daviewales]

I was just wondering that, but creating a symlink didn't change anything.

[testinfected]

On my MacPorts install, phonon.so is linked to a real libphonon.dylib:

otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so:
    /opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0, current version 4.7.1)
    /opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus (compatibility version 4.8.0, current version 4.8.6)
    /opt/local/Library/Frameworks/QtXml.framework/Versions/4/QtXml (compatibility version 4.8.0, current version 4.8.6)
    /opt/local/Library/Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.6)
    /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.6)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

[daviewales]

Here's an interesting piece of trivia:

The missing symbol is __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE0EE11qt_metacastEPKc.
That symbol can be found in /usr/local/lib/phonon.framework/Versions/4/phonon, which is apparently linked according to otool -L.

It can also be found in /usr/local/lib/python2.7/site-packages/PyQt4/phonon.so, which is the path that Python complains about.

[testinfected]

Interesting, on MacPorts /opt/local/lib/libphonon.4.dylib is actually simlinked to /opt/local/lib/libphonon.4.7.1.dylib installed by the phonon port.

If I change the simlink to /opt/local/Library/Frameworks/phonon.framework/phonon installed by PyQt, then I get the same error:

ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so, 2): Symbol not found: __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE0EE11qt_metacastEPKc
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so
  Expected in: /opt/local/lib/libphonon.4.dylib
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so

[daviewales]

That is very odd. But, I wonder if we can perform that process in reverse.

[testinfected]

If I replace Cellar/qt/4.8.6/Frameworks/phonon.framework/phonon with /opt/local/lib/libphonon.4.7.1.dylib then the import works fine.

[daviewales]

That's exactly what I wanted to know. That is very interesting.

[testinfected]

Can you help me use install_name_tool to change the dylinks of libphonon.4.7.1.dylib to the homebrew installation? I don't know how to do that

Here's what I have now:

otool -L Cellar/qt/4.8.6/Frameworks/phonon.framework/phonon
Cellar/qt/4.8.6/Frameworks/phonon.framework/phonon:
    /opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0, current version 4.7.1)
    /opt/local/Library/Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.5)
    /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.5)
    /opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus (compatibility version 4.8.0, current version 4.8.5)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

[daviewales]

The basic syntax is

install_name_tool -change [old-link-path] [new-link-path] file

It doesn't always work, however. (e.g. if the new link path is longer than the old link path, it can't change it.)

[testinfected]

I replaced the dynamic links to QtCore and QtGui, so now:

otool -L /usr/local/lib/phonon.framework/phonon
/usr/local/lib/phonon.framework/phonon:
    /opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0, current version 4.7.1)
    /usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.5)
    /usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.5)
    /opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus (compatibility version 4.8.0, current version 4.8.5)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

I can't replace the DBus link because my homebrew qt is not built with DBus and the macport version is by default.

So I can successfully run:

from PyQt4.phonon import phonon

but I have a dependency on the macports install. I will try rebuilding libphonon.4.dylib without linking to DBus.

[daviewales]

So, this is the MacPorts Phonon, with some of the links replaced by Homebrew links?

Now we just have to find out how MacPorts builds phonon, and build it ourselves.

I have tried building with KDE Phonon using Homebrew, and it didn't work, so they must be doing something more than just building KDE Phonon.

Here is the MacPorts port file.
https://trac.macports.org/browser/trunk/dports/audio/phonon/Portfile

Looking at it, they do a bunch of things and I'm not sure why they do them. However, it would be interesting to try to replicate them.

[testinfected]

Yes what's working for me right now is building Qt and PyQt with Homebrew then overwriting the Qt phonon framework with the MacPorts phonon libs after replacing the links with Homebrew links.

I still can't understand though why I am not able to make it work with Qt 4.8.5 and PyQt 4.10.3 as before. The only difference is that I'm using the new formulae to build Qt, Sip and PyQt. So could the cause be a change in the way we build them?

[daviewales]

I have no idea. I wonder if we could replicate the issue by building it outside of Homebrew.

[jacknagel]

Closing as stale, but discussion can continue here even though the issue is closed. If there is progress made, we can reopen.

[marcjordan]

I've been working on this this last weekend and I think I have a theory. My team had run into a weird issue where functions that were supposed to be inlined in code, were actually left the symbol table of the resulting library. This looks to be a bug in clang. The problem we're running into here manifests itself in a very similar way, so I think either it's the same bug, or one closely related. If you look at the symbol in question in the Homebrew Qt install, you can see it's a weak symbol in the library:

% nm /usr/local/lib/phonon.framework/phonon | grep ObjectDescriptionModel | grep metacast
000000000001a42e t __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE0EE11qt_metacastEPKc
000000000001a4c6 t __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE1EE11qt_metacastEPKc
000000000001a512 t __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE2EE11qt_metacastEPKc
000000000001a55e t __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE3EE11qt_metacastEPKc
000000000001a47a t __ZN6Phonon22ObjectDescriptionModelILNS_21ObjectDescriptionTypeE4EE11qt_metacastEPKc

Notice the lower-case 't' in front of the symbol. These are weak symbols, and I believe the clang bug is leaving them visible outside the library when they shouldn't be. In versions of Qt built with an earlier g++ compiler, these would have an upper-case "T" and be strong symbols that can be seen (and used) outside the library. This symbol is not the only one that needs to be visible, BTW.

In order to get this working with the new clang, I patched the code to set the visibility of these symbols to "default" like the older Qt builds:

--- a/src/3rdparty/phonon/phonon/objectdescriptionmodel.h   2015-05-07 07:14:47.000000000 -0700
+++ b/src/3rdparty/phonon/phonon/objectdescriptionmodel.h   2015-11-02 15:20:39.000000000 -0800
@@ -197,11 +197,11 @@
             Q_OBJECT_CHECK

             /** \internal */
-            static PHONON_TEMPLATE_CLASS_MEMBER_EXPORT const QMetaObject staticMetaObject;
+            static __attribute__((visibility ("default"))) const QMetaObject staticMetaObject;
             /** \internal */
-            PHONON_TEMPLATE_CLASS_MEMBER_EXPORT const QMetaObject *metaObject() const;
+            __attribute__((visibility ("default"))) const QMetaObject *metaObject() const;
             /** \internal */
-            PHONON_TEMPLATE_CLASS_MEMBER_EXPORT void *qt_metacast(const char *_clname);
+            __attribute__((visibility ("default"))) void *qt_metacast(const char *_clname);
             //int qt_metacall(QMetaObject::Call _c, int _id, void **_a);

             /**

(It might also be that the PHONON_TEMPLATE_CLASS_MEMBER_EXPORT macro is supposed to do this, and is somehow broken, but it just seems to be resolving to Q_DECL_EXPORT or Q_DECL_IMPORT under the covers, so I'm not sure why that wouldn't work.) By re-building Qt with this patch, and then re-building pyqt from source against it, I'm now able to get phonon to import with only Homebrew components.

For those interested in the clang bug, the discussion is here:
http://clang-developers.42468.n3.nabble.com/RFC-AlwaysInline-codegen-td4047298.html

[marcjordan]

Just realized that I didn't have to rebuild PyQt after all, only Qt.

[daviewales]

This is very interesting, but very much above my knowledge / skill level.