Till Oliver Knoll
till.oliver.knoll at gmail.com
Wed Sep 5 10:01:34 CEST 2012
2012/9/4 Alexander Carôt <a.carot at inf.hs-anhalt.de>:
> ...When I check
> the plugin binary regarding the required libs with otool -L trivial I get:
> localhost:MacOS soulalex$ otool -L trivial
> QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current
> version 4.7.4)
> If I compare this to Qt apps I built on MAC the distribution binaries show
> (compatibility version 4.8.0, current version 4.8.1)
Okay, so the issue can be tracked down to a wrong Qt version being
picked up. Fortunatelly this can be properly handled on Mac.
Unfortunatelly that requires quite some work on your side.
The magic keyword here is: install_name_tool (a Mac SDK/Xcode tool).
Basically Mac binaries have the (absolute or relative) paths hardcoded
into their "binary headers". Those can - and should! - be changed with
That is a bit tricky, as you need to have both the old (to be
replaced) path and the new path (typically a relative path, relative
to the actual executable). The old path is typically the path where
your developer Qt frameworks are installed (e.g.
/Users/YourUser/QtSDK/....), the new path will typically be a relative
path within the Application Bundle.
To make things even a bit more complicated you need to change BOTH the
ID of a given framework (e.g QtCore) AND the PATH of the executable,
such that it points to that new ID (basically - details are left for
the reader to discover ;))
All this is described in details here:
Unfortunatelly that applies if you want to build an Application Bundle
(with Qt plugins). But I assume if you place the Qt Frameworks
relative to a suitable place next to your browser plugin, the same
techniques should apply as well.
Note that for Application Bundles there exists a utility tool called
'qtmacdeploy' which does exactly the above steps: however in its
latest incarnation in Qt 4.8 it basically copies pretty much all Qt
libraries (also the ones your applicaiton doesn't really need) into
your Application Bundle (in theory qtmacdeploy should be smart enough
to figure out which Qt Frameworks and Plugins your application really
needs, e.g. by analysing the QT and CONFIG variables in your *.pro
file - in practise you can delete the unecessary Qt plugins in a
But again, qtmacdeploy is useful for Application Bundles, but you want
to do a browser plugin (does that also come as a Bundle?). So I guess
you have that "install_name_tool" wizardry yourself, e.g. with custom
target build steps in your *.pro (I did that as well).
Oh and yes, that is /not/ a particularity of Qt on Mac - this is how
you deploy any Framework and Application Bundle on Mac (but usually
that is hidden by automated steps in Xcode, I guess).
> Yes and now I copied it into the plugin folder and finally I can launch
> it. However, the result is the same as it is on MAC, so I guess this could
> also be a lib problem.
Just for testing: rename ALL your Qt installation folders, make sure
that they don't appear in the PATH etc. and only leave the expected Qt
version at a place where it can be found by your plugin (I don't know
where that would be - somewhere in the PATH? In the same location as
the plugin? In a "shared folder" where the browser looks for DLLs?
Again refer to above documentation).
Double-check that the Qt plugins (image plugins, for instance) can be
found as well by your browser plugin!
But thinking about it again for a second: wouldn't it make sense to
link your browser plugin statically anyway? I mean, how would you want
to distribute it anyway? With its own installer?
Also in general "dependency walker" is a /very/ helpful tool on
Windows to track down DLL dependency issues (google for it: it is a
free tool and also comes with the Windows SDK/Visual Studio).
More information about the Interest