Build qt4-mac plugins as bundles instead of dylibs

[clubjuggler@…]

After talking to Ben Reed, maintainer of the (non-macport) KDE/Mac packages ( ​http://mac.kde.org/ ) he alerted me to a problem with the standard qt4-mac build from Trolltech. See below for details:

Text taken from ​http://websvn.kde.org/trunk/qt-copy/patches/0231-mac-plugins.diff?view=markup&pathrev=816225

author: Benjamin Reed <rangerrick@…>

By default, Qt/Mac builds plugins as dynamic libraries, instead of bundles, which is incorrect for a runtime-loadable module. In addition, it calls them .dylib when they should be .bundle (or .so) by Mac convention (although this is just a cosmetic thing).

In addition, KDE phonon cannot load Qt phonon backends because they are built as normal twolevel dynamic libraries, which means that they try to use symbols from the library they were linked against, even if a newer version of that library is already loaded into memory. For example:

$QTDIR/plugins/phonon_backend/libphonon_qt7.dylib links to $QTDIR/lib/phonon.framework/Versions/4/phonon. Amarok links to $KDEDIR/lib/libphonon.4.dylib. At runtime, Amarok resolves it's phonon symbols to the $KDEDIR version, then dlopens libphonon_qt7 from $QTDIR which resolves some of those same symbols from the $QTDIR version of phonon, since it explicitly references the version it was linked against, rather than the version it was loaded into.

What you end up with is a dangling pointer.

For details on this, see Apple's documentation:

​http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_7.html

In short, the fix is to build plugins as bundles, with a flat namespace.

[erickt@…]

commited in r37370. Thanks again!

[(none)]

Milestone Port Bugs deleted