[MacPorts] #15502: Build qt4-mac plugins as bundles instead of dylibs

[MacPorts]

#15502: Build qt4-mac plugins as bundles instead of dylibs
-----------------------------------+----------------------------------------
 Reporter:  clubjuggler at gmail.com  |       Owner:  macports-tickets at lists.macosforge.org
     Type:  defect                 |      Status:  new                                  
 Priority:  Normal                 |   Milestone:  Port Bugs                            
Component:  ports                  |     Version:  1.6.0                                
 Keywords:  qt4-mac, kde4-mac      |  
-----------------------------------+----------------------------------------
 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 at befunk.com>

 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.

-- 
Ticket URL: <http://trac.macports.org/ticket/15502>
MacPorts <http://www.macports.org/>
Ports system for Mac OS