[Interest] Deploying Qt to MacOs still...errr, sucks?

[Daniel França]

Hi guys,
I know the subject is a little rude, but 2 years ago I'd a lot of problems
trying to deploy an app to OS X, as you can see here:
http://stackoverflow.com/questions/20895398/cant-deploy-qt-5-2-quick-app-to-mac-osx

You can see people with similar problems:
http://qt-project.org/forums/viewthread/48391
http://qt-project.org/forums/viewthread/50118

The solutions usually involves some custom script/app/macdeployqt.

Anyway, at that time I was able to deploy, but it sucked.
Now, 2 years later and with the fresh new Qt5.4, I'm again deploying Qt to
OSX and I faced similar problems.
Which led me to the question: Is anyone looking on that? Or am I doing
something terrible wrong?

I can't image that in 2 years no one cared about deployment on OSX.

Any feedback is welcome.

Best,
Daniel

[Nuno Santos]

Daniel,

To deploy a Mac OSX Qt Quick app do the following:

Imagine that your build was made to /tmp/build_YOUR_APP_NAME_clang_64_Release

cd /tmp
/PATH_TO_YOUR_QT/clang_64/bin/macdeployqt -qmldir=/path_to_your_app_source YOUR_APP_NAME.app

You need to run macdeployqt with the qmldir option, specifying the path of your qml files. This way, macdeployqt will analyse your qml source files and copy the respective plugins to the bundle.

Regards,

Nuno

Post by Daniel França
Hi guys,
I know the subject is a little rude, but 2 years ago I'd a lot of problems trying to deploy an app to OS X, as you can see here: http://stackoverflow.com/questions/20895398/cant-deploy-qt-5-2-quick-app-to-mac-osx <http://stackoverflow.com/questions/20895398/cant-deploy-qt-5-2-quick-app-to-mac-osx>
You can see people with similar problems: http://qt-project.org/forums/viewthread/48391 <http://qt-project.org/forums/viewthread/48391>
http://qt-project.org/forums/viewthread/50118 <http://qt-project.org/forums/viewthread/50118>
The solutions usually involves some custom script/app/macdeployqt.
Anyway, at that time I was able to deploy, but it sucked.
Now, 2 years later and with the fresh new Qt5.4, I'm again deploying Qt to OSX and I faced similar problems.
Which led me to the question: Is anyone looking on that? Or am I doing something terrible wrong?
I can't image that in 2 years no one cared about deployment on OSX.
Any feedback is welcome.
Best,
Daniel
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Till Oliver Knoll]

Post by Daniel França
...
The solutions usually involves some custom script/app/macdeployqt.

AFAIK the recommended way is still to run the 'macdeployqt' tool and then manually remove all unecessary Qt plugins ("manually" = "by qmake commands or own script").

That deals with the Qt dependency.

Any additional 3rd party library (not present on a virgin OS X) you have to treat yourself (read: "qmake commands" or a script) in the same way as macdeployqt does with the Qt libraries: the 'install_name_tool' becomes your close friend and the process should be deep in your DNA as a Mac Developer ;)

Last time I tried that I had no issues with that.

If you additionally want to deploy in the Mac App Store read the corresponding Qt docs. They explain what compiler/linker settings to set in order to get the necessary debug objects etc.

Cheers,
Oliver

[Daniel França]

I think the first parameter of macdeployqt must be the app bundle.

Trying this command I get a:
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*


To fix that I run the script on the answer here:
http://qt-project.org/forums/viewthread/50118 (Obs: It works only if I run
the script after generates the app bundle)

Then I've to rebuild my app, and add the -executable option to macdeployqt

And then I can have a working .dmg... but now complaining that it can't
find the sqlite driver can't be loaded... now I'm digging into how it finds
the sqlite driver.

Em Mon Feb 09 2015 at 6:16:06 PM, Nuno Santos <***@imaginando.pt>
escreveu:

Daniel,

Post by Nuno Santos
Imagine that your build was made to /tmp/build_YOUR_APP_NAME_
clang_64_Release
cd /tmp
/PATH_TO_YOUR_QT/clang_64/bin/macdeployqt -qmldir=/path_to_your_app_source
YOUR_APP_NAME.app
You need to run macdeployqt with the qmldir option, specifying the path of
your qml files. This way, macdeployqt will analyse your qml source files
and copy the respective plugins to the bundle.
Regards,
Nuno
Hi guys,
I know the subject is a little rude, but 2 years ago I'd a lot of problems
http://stackoverflow.com/questions/20895398/cant-
deploy-qt-5-2-quick-app-to-mac-osx
You can see people with similar problems: http://qt-project.
org/forums/viewthread/48391
http://qt-project.org/forums/viewthread/50118
The solutions usually involves some custom script/app/macdeployqt.
Anyway, at that time I was able to deploy, but it sucked.
Now, 2 years later and with the fresh new Qt5.4, I'm again deploying Qt to
OSX and I faced similar problems.
Which led me to the question: Is anyone looking on that? Or am I doing
something terrible wrong?
I can't image that in 2 years no one cared about deployment on OSX.
Any feedback is welcome.
Best,
Daniel
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Daniel França]

Thanks Oliver,
I definitely need to understand better how to use install_name_tool.
I'll look into that, but I think my case it should be simpler, as I don't
use any 3rd party library.

Post by Daniel França
I think the first parameter of macdeployqt must be the app bundle.
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
*ERROR: no file at "/opt/local/lib/libz.1.dylib"*
http://qt-project.org/forums/viewthread/50118 (Obs: It works only if I
run the script after generates the app bundle)
Then I've to rebuild my app, and add the -executable option to macdeployqt
And then I can have a working .dmg... but now complaining that it can't
find the sqlite driver can't be loaded... now I'm digging into how it finds
the sqlite driver.
Daniel,

Post by Nuno Santos
Imagine that your build was made to /tmp/build_YOUR_APP_NAME_clang
_64_Release
cd /tmp
/PATH_TO_YOUR_QT/clang_64/bin/macdeployqt -qmldir=/path_to_your_app_source
YOUR_APP_NAME.app
You need to run macdeployqt with the qmldir option, specifying the path
of your qml files. This way, macdeployqt will analyse your qml source files
and copy the respective plugins to the bundle.
Regards,
Nuno
Hi guys,
I know the subject is a little rude, but 2 years ago I'd a lot of
http://stackoverflow.com/questions/20895398/cant-deplo
y-qt-5-2-quick-app-to-mac-osx
You can see people with similar problems: http://qt-project.or
g/forums/viewthread/48391
http://qt-project.org/forums/viewthread/50118
The solutions usually involves some custom script/app/macdeployqt.
Anyway, at that time I was able to deploy, but it sucked.
Now, 2 years later and with the fresh new Qt5.4, I'm again deploying Qt
to OSX and I faced similar problems.
Which led me to the question: Is anyone looking on that? Or am I doing
something terrible wrong?
I can't image that in 2 years no one cared about deployment on OSX.
Any feedback is welcome.
Best,
Daniel
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Nuno Santos]

Sorry, I haven’t checked. I have just written directly.

I think it’s best to start with an empty project.

As Till Oliver said, you must be careful with additional dependencies.

If you don’t depend from nothing else than Qt itself you should have no problem.

Below is one working example for my case.

I’m on:

/Users/nsantos/workspace/

My project source is on:

/Users/nsantos/workspace/lkbridge

To deploy I run

~/Qt/5.4/clang_64_src/bin/macdeployqt build-lkbridge-Qt_5_4_Custom_Build-Debug/LKBRIDGE.app -qmldir=lkbridge/

on

/Users/nsantos/workspace/

Try with a new project first.

Nuno

Post by Daniel França
I think the first parameter of macdeployqt must be the app bundle.
ERROR: no file at "/opt/local/lib/libz.1.dylib"
ERROR: no file at "/opt/local/lib/libz.1.dylib"
ERROR: no file at "/opt/local/lib/libz.1.dylib"
ERROR: no file at "/opt/local/lib/libz.1.dylib"
To fix that I run the script on the answer here: http://qt-project.org/forums/viewthread/50118 <http://qt-project.org/forums/viewthread/50118> (Obs: It works only if I run the script after generates the app bundle)
Then I've to rebuild my app, and add the -executable option to macdeployqt
And then I can have a working .dmg... but now complaining that it can't find the sqlite driver can't be loaded... now I'm digging into how it finds the sqlite driver.
Daniel,
Imagine that your build was made to /tmp/build_YOUR_APP_NAME_clang_64_Release
cd /tmp
/PATH_TO_YOUR_QT/clang_64/bin/macdeployqt -qmldir=/path_to_your_app_source YOUR_APP_NAME.app
You need to run macdeployqt with the qmldir option, specifying the path of your qml files. This way, macdeployqt will analyse your qml source files and copy the respective plugins to the bundle.
Regards,
Nuno

Post by Daniel França
Hi guys,
I know the subject is a little rude, but 2 years ago I'd a lot of problems trying to deploy an app to OS X, as you can see here: http://stackoverflow.com/questions/20895398/cant-deploy-qt-5-2-quick-app-to-mac-osx <http://stackoverflow.com/questions/20895398/cant-deploy-qt-5-2-quick-app-to-mac-osx>
You can see people with similar problems: http://qt-project.org/forums/viewthread/48391 <http://qt-project.org/forums/viewthread/48391>
http://qt-project.org/forums/viewthread/50118 <http://qt-project.org/forums/viewthread/50118>
The solutions usually involves some custom script/app/macdeployqt.
Anyway, at that time I was able to deploy, but it sucked.
Now, 2 years later and with the fresh new Qt5.4, I'm again deploying Qt to OSX and I faced similar problems.
Which led me to the question: Is anyone looking on that? Or am I doing something terrible wrong?
I can't image that in 2 years no one cared about deployment on OSX.
Any feedback is welcome.
Best,
Daniel
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest <http://lists.qt-project.org/mailman/listinfo/interest>

[Till Oliver Knoll]

Post by Daniel França
...
ERROR: no file at "/opt/local/lib/libz.1.dylib"
...

Just recently there was a discussion that some pre-build Qt library errorneously links with libz located in /opt (Mac Ports), instead of /usr (=Apple).

You apparently just hit that same problem with Qt 5.4.

Cheers,
Oliver

[René J.V. Bertin]

Post by Till Oliver Knoll
Just recently there was a discussion that some pre-build Qt library errorneously links with libz located in /opt (Mac Ports), instead of /usr (=Apple).
You apparently just hit that same problem with Qt 5.4.

That discussion *was* about Qt 5.4 . Until Digia releases a new package, you can correct the dependency yourself:

%> install_name_tool -change /opt/local/lib/libz.1.dylib /usr/lib/libz.1.dylib /path/to/Qt5/5.4/clang_64/lib/QtCore.framework/QtCore

R.

[Hamish Moffatt]

Post by René J.V. Bertin

Post by Till Oliver Knoll
Just recently there was a discussion that some pre-build Qt library errorneously links with libz located in /opt (Mac Ports), instead of /usr (=Apple).
You apparently just hit that same problem with Qt 5.4.

%> install_name_tool -change /opt/local/lib/libz.1.dylib /usr/lib/libz.1.dylib /path/to/Qt5/5.4/clang_64/lib/QtCore.framework/QtCore

I think there are also problems with libxslt.1.dylib and
libsqlite3.0.dylib. macdeployqt is complaining here about both missing
from /opt/local/lib, and both are in /usr/lib.

Weirdly I also have macdeployqt complaining about missing
/Library/lib/Firebird.framework, even though no object in my Qt install
references that path. It does reference
/Library/Frameworks/Firebird.framework, but the path is getting munged
somewhere.

Hamish

[Thiago Macieira]

Post by Hamish Moffatt
I think there are also problems with libxslt.1.dylib and
libsqlite3.0.dylib. macdeployqt is complaining here about both missing
from /opt/local/lib, and both are in /usr/lib.

That must be the same MacPorts leak issue.

[Daniel França]

After create the .dmg with sql module on it, I ran this script:
http://pastebin.com/iR0bTb31
and then rebuild my project and regenerate the .dmg... then it works.

Not the smoothest deployment process, but at least it's working. (except
that it's full of aliasing even with antialising: true, but it's another
story)

Thanks guys,

Post by Thiago Macieira

Post by Hamish Moffatt
I think there are also problems with libxslt.1.dylib and
libsqlite3.0.dylib. macdeployqt is complaining here about both missing
from /opt/local/lib, and both are in /usr/lib.

That must be the same MacPorts leak issue.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[René J.V. Bertin]

Post by Daniel França
Not the smoothest deployment process, but at least it's working. (except
that it's full of aliasing even with antialising: true, but it's another
story)

IMHO Qt for Mac really should be able to use the fontconfig font engine like Qt for Windows can. When Freetype is installed with the Infinality patches it actually gives better text rendering than CoreText (and who knows, maybe Qt will also gain better support for less standard typefaces like medium or semi-bold, instead of replacing them with regular or bold).
If you want to file a request for that I'll +1 it.

Post by Daniel França

Post by Thiago Macieira
That must be the same MacPorts leak issue.

Yep. The "funny" part of that issue is that Qt's own binaries are generated with a HUGE "rpath" stored in them, which makes it possible to install the distribution just about anywhere and still have enough margin to edit those paths with a simple binary file editor (you can shorten static strings by putting a nullbyte somewhere, but you cannot of course lengthen them).
For some reason the packager decided not to use install_name_tool for that, and also forgot to take care of the MacPorts dependencies.
I don't know if install_name_tool is always present on user machines or if it requires the developer tools (which are required anyway for using what the Qt installer installs...). If one can rely on it, it seems a good idea to use that tool to adapt the Qt libraries to the user's chosen install location and handle any remaining MacPorts dependencies at the same time.
That's all the more true if the tool allows something like `install_name_tool -change /opt/local/lib /usr/lib`, i.e. a path change rather than a path+file change.

R.

[Daniel França]

Hmmm, why the font looks great on debug mode but looks blurry on
release/deployment?

Remember I told that I knew the steps to make the deployment works? Forget
it.... Tried again and can't make it consistent work.... the next attempt
only worked after I remove the -qmldir from macdeployqt(no idea why)... but
now it's not working anyway.

Gives me the error: *main.qml:1 module "QtQuick" plugin "qtquick2plugin"
not found *(doesn't matter if I add the -qmldir parameter or not)

And for now I'm stopping digging into that.

Best,
Daniel

Post by René J.V. Bertin

Post by Daniel França
Not the smoothest deployment process, but at least it's working. (except
that it's full of aliasing even with antialising: true, but it's another
story)

IMHO Qt for Mac really should be able to use the fontconfig font engine
like Qt for Windows can. When Freetype is installed with the Infinality
patches it actually gives better text rendering than CoreText (and who
knows, maybe Qt will also gain better support for less standard typefaces
like medium or semi-bold, instead of replacing them with regular or bold).
If you want to file a request for that I'll +1 it.

Post by Daniel França
Em Tue Feb 10 2015 at 4:32:58 AM, Thiago Macieira <

Post by Thiago Macieira
That must be the same MacPorts leak issue.

Yep. The "funny" part of that issue is that Qt's own binaries are
generated with a HUGE "rpath" stored in them, which makes it possible to
install the distribution just about anywhere and still have enough margin
to edit those paths with a simple binary file editor (you can shorten
static strings by putting a nullbyte somewhere, but you cannot of course
lengthen them).
For some reason the packager decided not to use install_name_tool for
that, and also forgot to take care of the MacPorts dependencies.
I don't know if install_name_tool is always present on user machines or if
it requires the developer tools (which are required anyway for using what
the Qt installer installs...). If one can rely on it, it seems a good idea
to use that tool to adapt the Qt libraries to the user's chosen install
location and handle any remaining MacPorts dependencies at the same time.
That's all the more true if the tool allows something like
`install_name_tool -change /opt/local/lib /usr/lib`, i.e. a path change
rather than a path+file change.
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Michael Jackson]

Post by René J.V. Bertin

Post by Thiago Macieira
That must be the same MacPorts leak issue.

Yep. The "funny" part of that issue is that Qt's own binaries are generated with a HUGE "rpath" stored in them, which makes it possible to install the distribution just about anywhere and still have enough margin to edit those paths with a simple binary file editor (you can shorten static strings by putting a nullbyte somewhere, but you cannot of course lengthen them).
For some reason the packager decided not to use install_name_tool for that, and also forgot to take care of the MacPorts dependencies.
I don't know if install_name_tool is always present on user machines or if it requires the developer tools (which are required anyway for using what the Qt installer installs...). If one can rely on it, it seems a good idea to use that tool to adapt the Qt libraries to the user's chosen install location and handle any remaining MacPorts dependencies at the same time.
That's all the more true if the tool allows something like `install_name_tool -change /opt/local/lib /usr/lib`, i.e. a path change rather than a path+file change.
R.

My guess is that the packager does not know about the "-headerpad_max_install_names" linker flag. This tells the linker to pad the "install_names" on the libraries to the max value so that one can change those "install_name" values. There really is NO Need to have some insanely long install path for the package when built. The "-headerpad_max_install_names" needs to be added to the Qt5 build scripts. I'll count that as an Obvious bug and not put in a report.

I was also the one that reported the MacPort dependency. And I am not really comfortable just changing the install_name to point towards another library of the same name but unknown as to how it was compiled or with what options. I'll count that as another obvious bug and not put in a bug report.

Lastly, CMake has very good support for creating a deployable .app package for OS X, even when using Qt 4/5. The issue with MacDeployQt (it is generally very good) is that our app has its own set of plugins that also need to be adjusted but MacDeployQt does not allow me to send in an additional list of Libraries/Plugins to get adjusted. MacDeployQt actually picked up and properly fixed my .app package including all my third party libraries like HDF5, TBB, Boost, ITK.

Now. if QtCreator could just better understand CMake projects I think I could have a decent experience coding with Qt.

Cheers
Mike Jackson

[René J.V. Bertin]

Post by Michael Jackson
I was also the one that reported the MacPort dependency. And I am not really comfortable just changing the install_name to point towards another library of the same name but unknown as to how it was compiled or with what options. I'll count that as another obvious bug and not put in a bug report.

This is a bit of a delicate matter. If Digia indeed use MacPorts to provide certain dependencies, it will not be that easy to avoid generic libraries like those reported, because it is MacPorts' principle to provide those libraries itself, but compiled with the default system compiler.
This is of no consequence as long as those in MacPorts are not so far ahead of the ones Apple ship that they become ABI incompatible. Nothing stops Digia from setting up (or having set up) a MacPorts environment that uses the same versions as Apple, and "simply" mark these ports as held, to borrow a Debian term.

Post by Michael Jackson
Now. if QtCreator could just better understand CMake projects I think I could have a decent experience coding with Qt.

Do you use a lot of ObjC code? If not, you could have a look at KDevelop. I actually prefer it over Creator in most aspects. You'd still need Creator or Xcode for debugging, though, because KDevelop doesn't support lldb yet.

R.

[Michael Jackson]

Post by René J.V. Bertin

Post by Michael Jackson
I was also the one that reported the MacPort dependency. And I am not really comfortable just changing the install_name to point towards another library of the same name but unknown as to how it was compiled or with what options. I'll count that as another obvious bug and not put in a bug report.

This is a bit of a delicate matter. If Digia indeed use MacPorts to provide certain dependencies, it will not be that easy to avoid generic libraries like those reported, because it is MacPorts' principle to provide those libraries itself, but compiled with the default system compiler.
This is of no consequence as long as those in MacPorts are not so far ahead of the ones Apple ship that they become ABI incompatible. Nothing stops Digia from setting up (or having set up) a MacPorts environment that uses the same versions as Apple, and "simply" mark these ports as held, to borrow a Debian term.

Post by Michael Jackson
Now. if QtCreator could just better understand CMake projects I think I could have a decent experience coding with Qt.

Do you use a lot of ObjC code? If not, you could have a look at KDevelop. I actually prefer it over Creator in most aspects. You'd still need Creator or Xcode for debugging, though, because KDevelop doesn't support lldb yet.
R.

Generally, because LLDB is still "new" when compared to gdb, *every body's* support for LLDB is very much sub-par at best for OS X. If you switch to Linux and use QtCreator to debug then the experience is enjoyable. Same thing for Visual Studio on Windows. Enjoyable. Debugger does not lockup, crash, I can see actual values in Qt Variables. You, know, stuff I would expect from debugging any modern C++ program. But the combination of OS X, with LLDB, CMake and QtCreator is just a non-starter at this point. Maybe someday. But not now.

I have had wonderful and enlightening conversations with a some of the Qt developers who kindly explained the issues as to why things are in the state they are in. I thank those that have enlightened me. I now have the proper perspective to make decisions for my company's development environment that allow us to be the most productive.

Cheers
Mike Jackson

[Mike Krus]

Hi all,

this tool is quite useful: https://github.com/auriamg/macdylibbundler <https://github.com/auriamg/macdylibbundler>
does the install_name_tool dance for the libs that macdeployqt ignores.
So I run macdeployqt, then dylibbundler
Then I still need a script to handle other plugins (for example of OSG).
And do the code signing

And build a nice dmg



Mike

[René J.V. Bertin]

On Wednesday February 11 2015 14:08:20 Mike Krus wrote:

I just noticed the following comment in the CMakeLists.txt file for CMake's own Qt app ...

# We need to install Cocoa platform plugin and add qt.conf for Qt5 on Mac.
# FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly
# Qt5 Mac support is missing there.

And build a nice dmg…

To kick in an open door: if you have everything in a single "distribution" folder, this command will take care of things:

%> hdiutil create -srcfolder "${SRC}" -volname "${NAME}" -format UDZO -imagekey zlib-level=9 -o "${DMG}" "$@"

That's a bare-bones dmg, though. For a fancier looking one, I find it easier to keep a RW image where I just modify changed contents. Adnd exactly like that, btw: I don't copy whole app bundles, but the Contents folder contained therein (by script or by hand). I suppose that fools the Finder into thinking the app didn't change, and so it's less likely to mess up the layout I set up.
Once done, I simply convert the RW image to a RO, compressed one, which is a procedure that creates a new image and leaves my RW image untouched.

R.

[Adam Light]

Post by Mike Krus
Hi all,
this tool is quite useful: https://github.com/auriamg/macdylibbundler
does the install_name_tool dance for the libs that macdeployqt ignores.
So I run macdeployqt, then dylibbundler
Then I still need a script to handle other plugins (for example of OSG).
And do the code signing

And build a nice dmg


If you're using Qt 5 (maybe only 5.4), macdeployqt may be able to help with
the code signing and possibly the dmg part:

/qtbuild5/install/mac64/bin/macdeployqt --help

Usage: macdeployqt app-bundle [options]

Options:

-verbose=<0-3> : 0 = no output, 1 = error/warning (default), 2 =
normal, 3 = debug

-no-plugins : Skip plugin deployment

-dmg : Create a .dmg disk image

-no-strip : Don't run 'strip' on the binaries

-use-debug-libs : Deploy with debug versions of frameworks and
plugins (implies -no-strip)

-executable=<path> : Let the given executable use the deployed
frameworks too

-qmldir=<path> : Deploy imports used by .qml files in the given path

-always-overwrite : Copy files even if the target file exists

-codesign=<ident> : Run codesign with the given identity on all
executables


I haven't tried using the -codesign flag because I came up with my own
script to do that before it was possible to do it using macdeployqt.

Adam

[Hamish Moffatt]

Post by Adam Light
If you're using Qt 5 (maybe only 5.4), macdeployqt may be able to help
/qtbuild5/install/mac64/bin/macdeployqt --help

Unfortunately that's not much use if you need to do anything more than
copy in Qt; for example bundle extra frameworks you are using, or remove
Qt plugins you don't need. If you do either of those then you need to
sign the app in your own scripts, because those operations will
invalidate any signing done by macdeployqt.

Of course macdeployqt could help by 1. supporting bundling other
frameworks (which it can find via otool, as it does to find which Qt
frameworks to bundle), and 2. allow you to include/exclude various Qt
plugins.

Right now it seems to bundle every plugin (or none, if you tell it to),
which is both a waste of space and a no-go with the Mac App store for us.


Hamish

[Jean-Michaël Celerier]

Late bump :

The documentation is still lacking.
For instance, where should one deploy QtQuick's QML files ?

Upon inspection it seems that some plug-ins are put in
Contents/PlugIns/quick, some QML files in Resources/qml (similarly to
what's in Qt/5.$version/$platform/qml folder) and symlinks in
Resources/qml/QtQuick (or others) to the actual qml plug-ins.

Is all of this necessary ?

Best,
Jean-Michaël



-------
Jean-Michaël Celerier
http://www.jcelerier.name

Post by Hamish Moffatt

Post by Adam Light
If you're using Qt 5 (maybe only 5.4), macdeployqt may be able to help
/qtbuild5/install/mac64/bin/macdeployqt --help

Unfortunately that's not much use if you need to do anything more than
copy in Qt; for example bundle extra frameworks you are using, or remove
Qt plugins you don't need. If you do either of those then you need to
sign the app in your own scripts, because those operations will
invalidate any signing done by macdeployqt.
Of course macdeployqt could help by 1. supporting bundling other
frameworks (which it can find via otool, as it does to find which Qt
frameworks to bundle), and 2. allow you to include/exclude various Qt
plugins.
Right now it seems to bundle every plugin (or none, if you tell it to),
which is both a waste of space and a no-go with the Mac App store for us.
Hamish
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Prashanth Udupa]

Hi Jean,

I am working on a project that involves deployment on Mac. I have a shell
script that packages the app into a DMG file or PKG file. It works for me
quite well. I am able to deploy a Qt 5.7 app to any Mac running Mac OS 10.8
and later.

1. Suppose that you are writing an app called "MyWonderfulApp". After
building the app, there will be a MyWonderfullApp.app/ folder in your
$$DESTDIR.
2. Suppose that you need to bundle a few more command line tools (which
link against Qt libs and maybe external DYLIBs) into your app-bundle.
3. Suppose also that you need to bundle additional DYLIBs.
4. Suppose also that you need to bundle QML components & desktop controls
that are referenced by your app.
5. Suppose that both MyWonderfullApp and the command-line-tool depends on
similar set of Qt frameworks and external libraries.

Below is usable snippets of the shell script. Hopefully they are of some
use to you. It will need more tweaking depending on your specific app and
its dependencies.

---------------
cd $DESTDIR

*# Copy command line tool to the app-bundle*
cp -vaRf cmdLineTool MyWonderfulApp.app/Contents/MacOS

*# Copy external libs to your app-bundle*
mkdir MyWonderfulApp.app/Contents/Frameworks
cp -vaRf /path/to/external/lib/externalLib.dylib
MyWonderfulApp.app/Contents/Frameworks/
install_name_tool -id @executable_path/../Frameworks/externalLib.dylib
MyWonderfulApp.app/Contents/Frameworks/externalLib.dylib

*# Map externalLib.dylib to a path within the app-bundle*
install_name_tool -change /path/to/external/lib/externalLib.dylib
@executable_path/../Frameworks/externalLib.dylib
MyWonderfulApp.app/Contents/MacOS/MyWonderfulApp
install_name_tool -change /path/to/external/lib/externalLib.dylib
@executable_path/../Frameworks/externalLib.dylib
MyWonderfulApp.app/Contents/MacOS/cmdLineTool

*# Map Qt frameworks used by cmdLineTool to the ones within the
app-bundle. *
*# (The frameworks will be copied when you use macdeployqt)*
install_name_tool -change @rpath/QtNetwork.framework/Versions/5/QtNetwork
@executable_path/../Frameworks/QtNetwork.framework/Versions/5/QtNetwork
MyWonderfulApp.app/Contents/MacOS/cmdLineTool
install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore
@executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore
MyWonderfulApp.app/Contents/MacOS/cmdLineTool
install_name_tool -change @rpath/QtXml.framework/Versions/5/QtXml
@executable_path/../Frameworks/QtXml.framework/Versions/5/QtXml
MyWonderfulApp.app/Contents/MacOS/cmdLineTool

*# Use macdeployqt to bundle everything else (frameworks, QML components,
Qt Desktop controls, plugins etc..)*
$QTDIR/macdeployqt MyWonderfulApp.app -always-overwrite
-qmldir=/path/to/qml_files_in_your_project -verbose=1 -appstore-compliant
-dmg

*# Now use MyWonderfulApp.dmg to distribute*
---------------

If you want to distribute your app as a pkg file, then change the
macdeployqt usage as follows

---------------
$QTDIR/macdeployqt MyWonderfulApp.app -always-overwrite
-qmldir=/path/to/qml_files_in_your_project -verbose=1 -appstore-compliant
productbuild --component MyWonderfulApp.app /Applications MyWonderfulApp.pkg

*# Distribute the MyWonderfulApp.pkg file now.*
---------------

Hope this helps.

Thanks,
Prashanth

On Thu, 10 Nov 2016 at 22:42 Jean-Michaël Celerier <

Post by Jean-Michaël Celerier
The documentation is still lacking.
For instance, where should one deploy QtQuick's QML files ?
Upon inspection it seems that some plug-ins are put in
Contents/PlugIns/quick, some QML files in Resources/qml (similarly to
what's in Qt/5.$version/$platform/qml folder) and symlinks in
Resources/qml/QtQuick (or others) to the actual qml plug-ins.
Is all of this necessary ?
Best,
Jean-Michaël

[Jake Petroules]

Post by Prashanth Udupa
Hi Jean,
I am working on a project that involves deployment on Mac. I have a shell script that packages the app into a DMG file or PKG file. It works for me quite well. I am able to deploy a Qt 5.7 app to any Mac running Mac OS 10.8 and later.
1. Suppose that you are writing an app called "MyWonderfulApp". After building the app, there will be a MyWonderfullApp.app/ folder in your $$DESTDIR.
2. Suppose that you need to bundle a few more command line tools (which link against Qt libs and maybe external DYLIBs) into your app-bundle.
3. Suppose also that you need to bundle additional DYLIBs.
4. Suppose also that you need to bundle QML components & desktop controls that are referenced by your app.
5. Suppose that both MyWonderfullApp and the command-line-tool depends on similar set of Qt frameworks and external libraries.
Below is usable snippets of the shell script. Hopefully they are of some use to you. It will need more tweaking depending on your specific app and its dependencies.
---------------
cd $DESTDIR
# Copy command line tool to the app-bundle
cp -vaRf cmdLineTool MyWonderfulApp.app/Contents/MacOS
# Copy external libs to your app-bundle
mkdir MyWonderfulApp.app/Contents/Frameworks
cp -vaRf /path/to/external/lib/externalLib.dylib MyWonderfulApp.app/Contents/Frameworks/

Don't do that last install_name_tool command. Instead, build your dynamic library with:

in qmake...
QMAKE_SONAME_PREFIX = @rpath (which is equivalent to QMAKE_LFLAGS += -Wl,-install_name,@rpath/externalLib.dylib)
or in qbs...
cpp.sonamePrefix: "@rpath"

and build your main application and command line helper tool with:

in qmake...
QMAKE_RPATHDIR += @loader_path/../Frameworks (which is equivalent to QMAKE_LFLAGS += -Wl,-rpath,@loader_path/../Frameworks)
or in qbs...

Post by Prashanth Udupa
# Map externalLib.dylib to a path within the app-bundle

Not needed, given the above.

Post by Prashanth Udupa
# Map Qt frameworks used by cmdLineTool to the ones within the app-bundle.
# (The frameworks will be copied when you use macdeployqt)

Also not needed, given the above.

Post by Prashanth Udupa
# Use macdeployqt to bundle everything else (frameworks, QML components, Qt Desktop controls, plugins etc..)
$QTDIR/macdeployqt MyWonderfulApp.app -always-overwrite -qmldir=/path/to/qml_files_in_your_project -verbose=1 -appstore-compliant -dmg
# Now use MyWonderfulApp.dmg to distribute
---------------
If you want to distribute your app as a pkg file, then change the macdeployqt usage as follows
---------------
$QTDIR/macdeployqt MyWonderfulApp.app -always-overwrite -qmldir=/path/to/qml_files_in_your_project -verbose=1 -appstore-compliant
productbuild --component MyWonderfulApp.app /Applications MyWonderfulApp.pkg
# Distribute the MyWonderfulApp.pkg file now.
---------------
Hope this helps.
Thanks,
Prashanth
The documentation is still lacking.
For instance, where should one deploy QtQuick's QML files ?
Upon inspection it seems that some plug-ins are put in Contents/PlugIns/quick, some QML files in Resources/qml (similarly to what's in Qt/5.$version/$platform/qml folder) and symlinks in Resources/qml/QtQuick (or others) to the actual qml plug-ins.
Is all of this necessary ?
Best,
Jean-Michaël
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

--
Jake Petroules - ***@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

[Prashanth Udupa]

Hi Jake,

Post by Prashanth Udupa
MyWonderfulApp.app/Contents/Frameworks/externalLib.dylib
in qmake...
or in qbs...

In my case, I use an external-lib provided by someone else. I cannot
rebuild it from source code - I can only link to it. Its available in
/usr/local/lib folder on my Mac while building. But it needs to be included
in the app-bundle for deployment.

In anycase, I did not know about QMAKE_SONAME_PREFIX. This is good, thanks!

Post by Prashanth Udupa
in qmake...
or in qbs...

I did not know this either. Thanks!

Thanks,
Prashanth

[Jake Petroules]

Post by Prashanth Udupa
Hi Jake,
in qmake...
or in qbs...
In my case, I use an external-lib provided by someone else. I cannot rebuild it from source code - I can only link to it. Its available in /usr/local/lib folder on my Mac while building. But it needs to be included in the app-bundle for deployment.

In that case your install_name_tool command should be:

install_name_tool -id @rpath/externalLib.dylib /usr/local/lib/externalLib.dylib

Just run that once on your global copy and you don't need to run it again each time you build your app since it will work for copying to any application.

I'd also recommend reading up on Run-Path Dependent Libraries at Apple Developer: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html#//apple_ref/doc/uid/TP40008306-SW1 which explains the concept of relocatability in depth.

Post by Prashanth Udupa
In anycase, I did not know about QMAKE_SONAME_PREFIX. This is good, thanks!
in qmake...
or in qbs...
I did not know this either. Thanks!
Thanks,
Prashanth

[René J.V. Bertin]

Post by Daniel França
Hi guys,
I know the subject is a little rude, but 2 years ago I'd a lot of problems
http://stackoverflow.com/questions/20895398/cant-deploy-qt-5-2-quick-app-to-mac-osx

...

Post by Daniel França
I can't image that in 2 years no one cared about deployment on OSX.
Any feedback is welcome.

Any? Ok :)

FWIW, have a look at the Charm time tracker: https://github.com/KDAB/Charm . It uses cmake instead of bare qmake, but that might actually allow you to generate an Xcode project.

Anyway, it bundles the application for standard OS X style deployment in the install phase, using cmake scripts that I haven't tried to analyse but could serve as an example. The only thing it misses for some reason is the cocoa platform plugin. Rather annoying as nothing works without it of course, but probably easy enough to correct.

Just take care to invoke cmake such that it finds the appropriate qmake and cmake modules, e.g.

%> env PATH="/usr/local/qt/5/5.4/clang_64/bin:$PATH" cmake .. -DCMAKE_MODULE_PATH=/usr/local/qt/5/5.4/clang_64/lib/cmake

do a make followed by

%> make install DESTDIR=someplace

which will create someplace/Applications/ with a standalone Charm.app inside.

Sounds easy enough to me if you can address the platform plugin issue, and as I said, cmake is capable of generating Xcode projects, if Qt Creator's native support for cmake projects doesn't cut it for you.

Enjoy :)

R.

[Daniel França]

Thanks for the tip René, for now I'm trying to really understand
install_name_tool.

I thought I did :P

But then after run the script that fixes the dylibs, and copy the
libsqlite.dylib to /MyBundle.app/Contents/PlugIns/sqlidrivers/

otool -L output:
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib:
libqsqlite.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/username/Qt5.4.0/5.4/clang_64/lib/QtSql.framework/Versions/5/QtSql
(compatibility version 5.4.0, current version 5.4.0)
/Users/username/Qt5.4.0/5.4/clang_64/lib/QtCore.framework/Versions/5/QtCore
(compatibility version 5.4.0, current version 5.4.0)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
version 1.0.0, current version 275.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)

The error is that it's referencing my local Qt for QtCore and QtSql, right?
So I supposed I should run install_name_tool to change that.

So I did:
*install_name_tool -change ~/Qt5.4.0/5.4/clang_64/lib/QtSql.framework/QtSql
@executable_path/../Frameworks/QtSql.framework/QtSql
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib*

*install_name_tool -change
~/Qt5.4.0/5.4/clang_64/lib/QtCore.framework/QtCore
@executable_path/../Frameworks/QtCore.framework/QtCore
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib*

I don't receive any output running those commands, not failure neither
successful
But didn't work =/ I keep getting the same error message when I run the
bundled app:

*dataStorage.js:33: Error: Driver not loaded Driver not loaded*
Any idea what can solve this issue?

Post by Till Oliver Knoll

Post by Till Oliver Knoll
Just recently there was a discussion that some pre-build Qt library

errorneously links with libz located in /opt (Mac Ports), instead of /usr
(=Apple).

Post by Till Oliver Knoll
You apparently just hit that same problem with Qt 5.4.

That discussion *was* about Qt 5.4 . Until Digia releases a new package,
%> install_name_tool -change /opt/local/lib/libz.1.dylib
/usr/lib/libz.1.dylib /path/to/Qt5/5.4/clang_64/lib/
QtCore.framework/QtCore
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Daniel França]

When you realize you sent an email too soon =/
The driver not being loaded was just that it was missing in the .pro
file += sql

Post by Daniel França
Thanks for the tip René, for now I'm trying to really understand
install_name_tool.
I thought I did :P
But then after run the script that fixes the dylibs, and copy the
libsqlite.dylib to /MyBundle.app/Contents/PlugIns/sqlidrivers/
libqsqlite.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/username/Qt5.4.0/5.4/clang_64/lib/QtSql.framework/Versions/5/QtSql
(compatibility version 5.4.0, current version 5.4.0)
/Users/username/Qt5.4.0/5.4/clang_64/lib/QtCore.framework/Versions/5/QtCore
(compatibility version 5.4.0, current version 5.4.0)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
version 1.0.0, current version 275.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)
The error is that it's referencing my local Qt for QtCore and QtSql,
right? So I supposed I should run install_name_tool to change that.
*install_name_tool -change
~/Qt5.4.0/5.4/clang_64/lib/QtSql.framework/QtSql
@executable_path/../Frameworks/QtSql.framework/QtSql
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib*
*install_name_tool -change
~/Qt5.4.0/5.4/clang_64/lib/QtCore.framework/QtCore
@executable_path/../Frameworks/QtCore.framework/QtCore
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib*
I don't receive any output running those commands, not failure neither
successful
But didn't work =/ I keep getting the same error message when I run the
*dataStorage.js:33: Error: Driver not loaded Driver not loaded*
Any idea what can solve this issue?

Post by Till Oliver Knoll

Post by Till Oliver Knoll
Just recently there was a discussion that some pre-build Qt library

errorneously links with libz located in /opt (Mac Ports), instead of /usr
(=Apple).

Post by Till Oliver Knoll
You apparently just hit that same problem with Qt 5.4.

That discussion *was* about Qt 5.4 . Until Digia releases a new package,
%> install_name_tool -change /opt/local/lib/libz.1.dylib
/usr/lib/libz.1.dylib /path/to/Qt5/5.4/clang_64/lib/
QtCore.framework/QtCore
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[René J.V. Bertin]

Thanks for the tip René, for now I'm trying to really understand
install_name_tool.
I thought I did :P

Don't worry, I don't think you're the only one :)

The error is that it's referencing my local Qt for QtCore and QtSql, right?
So I supposed I should run install_name_tool to change that.

Yes. Sounds like the script may skip plugins?

*install_name_tool -change ~/Qt5.4.0/5.4/clang_64/lib/QtSql.framework/QtSql
@executable_path/../Frameworks/QtSql.framework/QtSql
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib*
*install_name_tool -change
~/Qt5.4.0/5.4/clang_64/lib/QtCore.framework/QtCore
@executable_path/../Frameworks/QtCore.framework/QtCore
MyBundle.app/Contents/PlugIns/sqldrivers/libqsqlite.dylib*
I don't receive any output running those commands, not failure neither
successful

Not getting an error is a good sign, but that doesn't mean you gave the correct input. I'd try with a full path instead of using the tilde for referring to your homedir; too often I've had to handle expansion of that notation in my own code so I no longer trust shells to do it for me.

I presume you checked the effect of your command with otool? And the location where plugins have to be stored. Oh, and you're not by chance running on a case-sensitive filesystem and using your own capitalisation (PlugIns where the distribution directory has plugins in all lower case)?!


R.