[Qt-creator] Plugins implementation issue for QtCreator 3.3.0 under Mac OS X

[Henry Skoglund]

Re: plugins in OSX, I also discovered this, but what I do, every time 
after I rebuild my plugin and copy it to inside Qt Creator, I run a 
shell script to fixup the paths, I've included it below. It might be 
useful for you also.

Rgrds Henry

-----------------------------------------------------------------------------------
#!/bin/bash
#
# HS 2014-02-07 Updated for Qt 5.2
# HS 2014-02-22 Qt 5.2.1
# HS 2014-05-21 Qt 5.3.1 and Qt Creator 3.1.2
# HS 2015-01-04 Qt 5.4 and Qt Creator 3.3
#
# Solve the double QT runtime problem in OSX for QtCreator plugins by 
running install_name_tool on our plugin dll.
# This will change the pickup path for the common five framework DLLs 
used by most plugins:
# QtCore, QtConcurrent, QtGui, QtNetwork and QtWidgets.
# So we change the path from  the "unbundled" compiler specific 
framework versions to the "bundled" ones inside the QtCreator app.
#
install_name_tool -change 
/Users/henry/Qt/5.4/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets 
      /Users/henry/Qt/Qt\ 
Creator.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets 
       /Users/henry/Qt/Qt\ Creator.app/Contents/PlugIns/myFancyPlugin.dylib
install_name_tool -change 
/Users/henry/Qt/5.4/clang_64/lib/QtGui.framework/Versions/5/QtGui 
         /Users/henry/Qt/Qt\ 
Creator.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui 
        /Users/henry/Qt/Qt\ Creator.app/Contents/PlugIns/myFancyPlugin.dylib
install_name_tool -change 
/Users/henry/Qt/5.4/clang_64/lib/QtCore.framework/Versions/5/QtCore 
         /Users/henry/Qt/Qt\ 
Creator.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore 
        /Users/henry/Qt/Qt\ Creator.app/Contents/PlugIns/myFancyPlugin.dylib
install_name_tool -change 
/Users/henry/Qt/5.4/clang_64/lib/QtConcurrent.framework/Versions/5/QtConcurrent 
/Users/henry/Qt/Qt\ 
Creator.app/Contents/Frameworks/QtConcurrent.framework/Versions/5/QtConcurrent 
/Users/henry/Qt/Qt\ Creator.app/Contents/PlugIns/myFancyPlugin.dylib
install_name_tool -change 
/Users/henry/Qt/5.4/clang_64/lib/QtNetwork.framework/Versions/5/QtNetwork 
      /Users/henry/Qt/Qt\ 
Creator.app/Contents/Frameworks/QtNetwork.framework/Versions/5/QtNetwork 
       /Users/henry/Qt/Qt\ Creator.app/Contents/PlugIns/myFancyPlugin.dylib
-----------------------------------------------------------------------------------

On 2015-02-06 09:22, Ziller Eike wrote:
>
>> On Jan 31, 2015, at 13:10, Maskim Klimov <cleemmi at gmail.com> wrote:
>>
>> It looks like there are some problems with running QtCreator external plugins under Mac OS X.
>> 1. The function "bool MimeDatabase::addMimeTypes(const QString &fileName, QString *errorMessage)".
>>    It simply opens the file and passes it to "bool MimeDatabasePrivate::addMimeTypes(QIODevice *device, const QString &fileName, QString *errorMessage)». But It fails to open the file from plugin project resources under Mac OS X. On the contrary, manual file opening and invoking "bool MimeDatabase::addMimeTypes(QIODevice *device, QString *errorMessage)» works good.
>> It seems like resource files are not shared between the plugin and QtCreator instance (may be it is global problem with Qt resources under Mac OS X).
>>
>> 2. Pure virtual method QWidget* Core::IOptionsPage::widget().
>>    I implemented derived class with constructor that set desired options category, icon, etc. I overrode this function with simple creation of QWidget (or derived class) instance. On the QtCreator’ option page I can see my option category but a click on it leads to QtCreator’ crash with message "QWidget: Must construct a QApplication before a QWidget».
>>
>> By the way, I have no such problems under Linux.
>
> If you run your plugin against a Qt Creator binary package on OS X, you must make sure that you change your plugin’s referred to install names to the Qt frameworks from absolute paths to something that resolves to the Qt libraries that are shipped with Qt Creator. If you don’t, the dynamic linker will load two instances of the Qt libraries, which sounds like it could lead to the problems you observe above. You probably get messages on the console/terminal from the dynamic linker that symbols are defined twice and it is undefined which are taken in which situations.
>
> If you run "otool -L" on your libMyPlugin.dylib you’ll see stuff like
> /Users/Shared/qt/qt/5.4/64/qtbase/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.4.0, current version 5.4.2)
>
> You need to change these paths to "@rpath/Frameworks/QtCore.framework/Versions/5/QtCore” etc with install_name_tool, e.g.
> install_name_tool -change /Users/Shared/qt/qt/5.4/64/qtbase/lib/QtCore.framework/Versions/5/QtCore @rpath/Frameworks/QtCore.framework/Versions/5/QtCore libMyPlugin.dylib
>
> The rpath of your plugin should already have a sensible value (including @executable_path/../). You can check by running “otool -l” (lower-case L) on your plugin library and look for cmd LC_RPATH entries (there can be multiple).
>
> Br, Eike
>