macOS (previously known as OS X or Mac OS X) is Apple's operating system for the Mac line of computers. It's a UNIX platform, based on the Darwin kernel, and behaves largely similar to other UNIX-like platforms. The main difference is that X11 is not used as the windowing system. Instead, macOS uses its own native windowing system that is accessible through the Cocoa API.
A couple of years back, I was developing an application for Ubuntu. For unspecified reasons, I wanted to develop the GUI in Qt/C, but implement all logic in Python. The default Python that came with Ubuntu at the time could not run my scripts, so I had to ship a compatible Python version along with my application. Basically, I had to embed the Python interpreter into my program, by linking. Hi Volker, I've tried your solution on Mac OS X 10.9.1 using a simple AppleScript to retrieve a mail subject from Apple Mail. The script needs around 1 sec to execute with the AppleScript Editor application, but around 20-30 secs when using QProcess/osascript. Running osascript from a shell window also needs around 1 sec for the script. Deploying an Qt application does not require any C programming. All you need to do is to build Qt and your application in release mode, following the procedures described in this documentation. Shared Libraries. There are two ways of deploying an application: Static Linking; Shared Libraries (Frameworks on Mac).
To download and install Qt for macOS, follow the instructions on the Getting Started with Qt page.
Qt for macOS - Deployment The Bundle. On macOS, a GUI application must be built and run from a bundle, which is a directory structure that appears. If you want to keep things simple and have a few files to deploy, you must build your application with. Add Administrator Level Privileges to Your Qt Program Include the following in your project’s PRO file to have Administrator level privileges added to your program. Following should be noted while using this.
Supported Versions
When talking about version support on macOS, it's important to distinguish between the build environment; the platform you're building on or with, and the target platforms; the platforms you are building for. The following macOS versions are supported.
Build Environment
The build environment on macOS is defined entirely by the Xcode version used to build your application. Xcode contains both a toolchain (compiler, linker, and other tools), and a macOS platform-SDK (headers and libraries). Together these define how your application is built.
Note: The version of macOS that you are running Xcode on does not matter. As long as Apple ships a given Xcode version that runs on your operating system, the build environment will be defined by that Xcode version.
Xcode can be downloaded from Apple's developer website (including older versions of Xcode). Once installed, choosing an Xcode installation is done using the
xcode-select tool.
You can inspect the globally selected Xcode installation using the same tool.
The
xcrun command can then be used to find a particular tool in the toolchain.
or show the platform SDK path used when building.
Target Platforms
Building for macOS utilizes a technique called weak linking that allows you to build your application against the headers and libraries of the latest platform SDK, while still allowing your application to be deployed to macOS versions lower than the SDK version. When the binary is run on a macOS version lower than the SDK it was built with, Qt will check at runtime whether or not a platform feature is available before utilizing it.
In theory this would allow running your application on every single macOS version released, but for practical (and technical) reasons there is a lower limit to this range, known as the deployment target of your application. If the binary is launched on a macOS version below the deployment target macOS or Qt will give an error message and the application will not run.
Qt expresses the deployment target via the
QMAKE_MACOSX_DEPLOYMENT_TARGET qmake variable, which has a default value set via the makespec for macOS. You should not need to change this default, but if needed you can increase it in your project file:
Note: You should not lower the deployment target beyond the default value set by Qt. Doing so will likely lead to crashes at runtime if the binary is then deployed to a macOS version lower than what Qt expected to run on.
By always building against the latest available platform SDK, you ensure that Qt can take advantage of new features introduced in recent versions of macOS.
For more information about SDK-based development on macOS, see Apple's developer documentation.
Opting out of macOS behavior changes
One caveat to using the latest Xcode version and SDK to build your application is that macOS's system frameworks will sometimes decide whether or not to enable behavior changes based on the SDK you built your application with.
For example, when dark-mode was introduced in macOS 10.14 Mojave, macOS would only treat applications built against the 10.14 SDK as supporting dark-mode, and would leave applications built against earlier SDKs with the default light mode look. This technique allows Apple to ensure that binaries built long before the new SDK and operating system was released will still continue to run without regressions on new macOS releases.
A consequence of this is that if Qt has problems dealing with some of these macOS features (dark-mode, layer-backed views), the only way to opt out of them is building with an earlier SDK (the 10.13 SDK, available through Xcode 9). This is a last-resort solution, and should only be applied if your application has no other ways of working around the problem.
Architectures
By default, Qt is built for x86_64. To build for x86_64h (Haswell). use the
QMAKE_APPLE_DEVICE_ARCHS qmake variable. This is selectable at configure time:
QMAKE_APPLE_DEVICE_ARCHS can also be specified as a space-delimited list in order to build for multiple architectures simultaneously:
Additional Command-Line Options
On the command-line, applications can be built using
qmake and make . Optionally, qmake can generate project files for Xcode with -spec macx-xcode . If you are using the binary package, qmake generates Xcode projects by default; use -spec macx-gcc to generate makefiles. For example:
Configuring with
-spec macx-xcode generates an Xcode project file from project.pro. With qmake you do not have to worry about rules for Qt's preprocessors (moc and uic) since qmake automatically handles them and ensures that everything necessary is linked into your application.
Qt does not entirely interact with the development environment (for example plugins to set a file to 'mocable' from within the Xcode user interface).
The result of the build process is an application bundle, which is a directory structure that contains the actual application executable. The application can be launched by double-clicking it in Finder, or by referring directly to its executable from the command line, for example,
myApp.app/Contents/MacOS/myApp .
If you wish to have a command-line tool that does not use the GUI for example,
moc , uic or ls , you can tell qmake to disable bundle creation from the CONFIG variable in the project file:
Deploying Applications on macOS
macOS applications are typically deployed as self-contained application bundles. The application bundle contains the application executable as well as dependencies such as the Qt libraries, plugins, translations and other resources you may need. Third party libraries like Qt are normally not installed system-wide; each application provides its own copy.
A common way to distribute applications is to provide a compressed disk image (.dmg file) that the user can mount in Finder. The deployment tool,
macdeployqt (available from the macOS installers), can be used to create the self-contained bundles, and optionally also create a .dmg archive. Applications can also be distributed through the Mac App Store. Qt 5 aims to stay within the app store sandbox rules. macdeployqt (bin/macdeployqt) can be used as a starting point for app store deployment.
Note: For selling applications in the macOS App Store, special rules apply. In order to pass validation, the application must verify the existence of a valid receipt before executing any code. Since this is a copy protection mechanism, steps should be taken to avoid common patterns and obfuscate the code that validates the receipt as much as possible. Thus, this cannot be automated by Qt, but requires some platform-specific code written specifically for the application itself. More information can be found in Apple's documentation.
macOS Issues
The page below covers specific issues and recommendations for creating macOS applications.
Where to Go from Here
We invite you to explore the rest of Qt. We prepared overviews to help you decide which APIs to use and our examples demonstrate how to use our API.
Qt's vibrant and active community site, http://qt.io houses a wiki, a forum, and additional learning guides and presentations.
© 2020 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
Beginning with Qt 4.5, a deployment tool is included that automates the prodecures described here.
This document describes how to create a bundle and how to make sure that the application will find the resources it needs at run-time. We demonstrate the procedures in terms of deploying the Plug & Paint application that is provided in Qt's examples directory.
The Bundle
On the Mac, a GUI application must be built and run from a bundle. Mac app store. A bundle is a directory structure that appears as a single entity when viewed in the Finder. A bundle for an application typcially contains the executable and all the resources it needs. See the image below:
The bundle provides many advantages to the user. One primary advantage is that, since it is a single entity, it allows for drag-and-drop installation. As a programmer you can access bundle information in your own code. This is specific to Mac OS X and beyond the scope of this document. More information about bundles is available on Apple's Developer Website.
A Qt command line application on Mac OS X works similar to a command line application on Unix and Windows. You probably don't want to run it in a bundle: Add this to your application's .pro:
This will tell
qmake not to put the executable inside a bundle. Please refer to the X11 deployment documentation for information about how to deploy these 'bundle-less' applications.
Xcode
We will only concern ourselves with command-line tools here. While it is possible to use Xcode for this, Xcode has changed enough between each version that it makes it difficult to document it perfectly for each version. A future version of this document may include more information for using Xcode in the deployment process.
Static Linking
If you want to keep things simple by only having a few files to deploy, then you must build everything statically.
Building Qt Statically
Start by installing a static version of the Qt library. Remember that you will not be able to use plugins and you must build in all the image formats, SQL drivers, etc.
You can check the various options that are available by running
configure -help.
Linking the Application to the Static Version of Qt
Once Qt is built statically, the next step is to regenerate the makefile and rebuild the application. First, we must go into the directory that contains the application:
Now run
qmake to create a new makefile for the application, and do a clean build to create the statically linked executable:
You probably want to link against the release libraries, and you can specify this when invoking
qmake . If you have Xcode Tools 1.5 or higher installed, you may want to take advantage of 'dead code stripping' to reduce the size of your binary even more. You can do this by passing LIBS+= -dead_strip to qmake in addition to the -config release parameter. This doesn't have as large an effect if you are using GCC 4, since Qt will then have function visibility hints built-in, but if you use GCC 3.3, it could make a difference.
Now, provided that everything compiled and linked without any errors, we should have a
plugandpaint.app https://spinyellow297.weebly.com/download-nfs-most-wanted-highly-compressed-350mb-for-android.html. bundle that is ready for deployment. One easy way to check that the application really can be run stand-alone is to copy the bundle to a machine that doesn't have Qt or any Qt applications installed, and run the application on that machine.
You can check what other libraries your application links to using the
otool :
Here is what the output looks like for the static Plug & Paint:
Copied mac app crack. For more information, see the Application Dependencies section.
If you see Qt libraries in the output, it probably means that you have both dynamic and static Qt libraries installed on your machine. The linker will always choose dynamic over static. There are two solutions: Either move your Qt dynamic libraries (
.dylibs ) away to another directory while you link the application and then move them back, or edit the Makefile and replace link lines for the Qt libraries with the absolute path to the static libraries. For example, replace
with
The Plug & Paint example consists of several components: The core application (Plug & Paint), and the Basic Tools and Extra Filters plugins. Since we cannot deploy plugins using the static linking approach, the bundle we have prepared so far is incomplete. The application will run, but the functionality will be disabled due to the missing plugins. To deploy plugin-based applications we should use the framework approach.
Frameworks
We have two challenges when deploying the Plug & Paint application using frameworks: The Qt runtime has to be correctly redistributed along with the application bundle, and the plugins have to be installed in the correct location so that the application can find them.
When distributing Qt with your application using frameworks, you have two options: You can either distribute Qt as a private framework within your application bundle, or you can distribute Qt as a standard framework (alternatively use the Qt frameworks in the installed binary). These two approaches are essentially the same. The latter option is good if you have many Qt applications and you would prefer to save memory. The former is good if you have Qt built in a special way, or want to make sure the framework is there. It just comes down to where you place the Qt frameworks.
Building Qt as Frameworks
We assume that you already have installed Qt as frameworks, which is the default when installing Qt, in the /path/to/Qt directory. For more information on how to build Qt, see the Installation documentation.
When installing, the identification name of the frameworks will also be set. The identification name is what the dynamic linker (
dyld ) uses to find the libraries for your application.
Linking the Application to Qt as Frameworks
After ensuring that Qt is built as frameworks, we can build the Plug & Paint application. First, we must go into the directory that contains the application:
Now run qmake to create a new makefile for the application, and do a clean build to create the dynamically linked executable:
This builds the core application, the following will build the plugins:
Now run the
otool for the Qt frameworks, for example Qt Gui:
You will get the following output:
For the Qt frameworks, the first line (i.e.
path/to/Qt/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.0.0, current version 4.0.1) ) becomes the framework's identification name which is used by the dynamic linker (dyld ). C++ visual studio download mac.
But when you are deploying the application, your users may not have the Qt frameworks installed in the specified location. https://beastbela.weebly.com/free-download-wallpaper-for-android-huawei.html. For that reason, you must either provide the frameworks in an agreed upon location, or store the frameworks in the bundle itself. Regardless of which solution you choose, you must make sure that the frameworks return the proper identification name for themselves, and that the application will look for these names. Luckily we can control this with the
install_name_tool command-line tool.
The
install_name_tool works in two modes, -id and -change . The -id mode is for libraries and frameworks, and allows us to specify a new identification name. We use the -change mode to change the paths in the application.
Let's test this out by copying the Qt frameworks into the Plug & Paint bundle. Looking at
otool 's output for the bundle, we can see that we must copy both the QtCore and QtGui frameworks into the bundle. We will assume that we are in the directory where we built the bundle.
First we create a
Frameworks directory inside the bundle. This follows the Mac OS X application convention. We then copy the frameworks into the new directory. Since frameworks contain symbolic links, and we want to preserve them, we use the -R option.
Then we run
install_name_tool to set the identification names for the frameworks. The first argument after -id is the new name, and the second argument is the framework which identification we wish to change. The text @executable_path is a special dyld variable telling dyld to start looking where the executable is located. The new names specifies that these frameworks will be located 'one directory up and over' in the Frameworks directory.
Now, the dynamic linker knows where to look for QtCore and QtGui. Then we must make the application aware of the library locations as well using
install_name_tool 's -change mode. This basically comes down to string replacement, to match the identification names that we set for the frameworks.
Finally, since the QtGui framework depends on QtCore, we must remember to change the reference for QtGui:
After all this we can run
otool again and see that the application will look in the right locations.
Of course, the thing that makes the Plug & Paint example interesting are its plugins. The basic steps we need to follow with plugins are:
While we can put the plugins anywhere we want in the bundle, the best location to put them is under Contents/Plugins. When we built the Plug & Paint plugins, the
DESTDIR variable in their .pro file put the plugins' .dylib files in a plugins subdirectory in the plugandpaint directory. So, in this example, all we need to do is move this directory:
If we run
otool on for example the Basic Tools plugin's .dylib file we get the following information.
Then we can see that the plugin links to the Qt frameworks it was built against. Since we want the plugins to use the framework in the application bundle we change them the same way as we did for the application. For example for the Basic Tools plugin:
We must also modify the code in
tools/plugandpaint/mainwindow.cpp to cdUp() one directory since the plugins live in the bundle. Add the following code to the mainwindow.cpp file:
Warning: When deploying plugins, and thus make changes to the source code, the default identification names are reset when rebuilding the application, and you must repeat the process of making your application link to the Qt frameworks in the bundle using
install_name_tool .
Now you should be able to move the application to another Mac OS X machine and run it without Qt installed. Alternatively, you can move your frameworks that live outside of the bundle to another directory and see if the application still runs.
If you store the frameworks in another location than in the bundle, the technique of linking your application is similar; you must make sure that the application and the frameworks agree where to be looking for the Qt libraries as well as the plugins.
Creating the Application Package![]()
When you are done linking your application to Qt, either statically or as frameworks, the application is ready to be distributed. Apple provides a fair bit of information about how to do this and instead of repeating it here, we recommend that you consult their software delivery documentation.
Although the process of deploying an application do have some pitfalls, once you know the various issues you can easily create packages that all your Mac OS X users will enjoy.
Application DependenciesQt Plugins
Your application may also depend on one or more Qt plugins, such as the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application, and note that each type of plugin should be located within a specific subdirectory (such as
imageformats or sqldrivers ) within your distribution directory, as described below.
Uninstall Qt Mac
Note: If you are deploying an application that uses QtWebKit to display HTML pages from the World Wide Web, you should include all text codec plugins to support as many HTML encodings possible.
The search path for Qt plugins (as well as a few other paths) is hard-coded into the QtCore library. By default, the first plugin search path will be hard-coded as
/path/to/Qt/plugins . But using pre-determined paths has certain disadvantages. For example, they may not exist on the target machine. For that reason you need to examine various alternatives to make sure that the Qt plugins are found:
The How to Create Qt Plugins document outlines the issues you need to pay attention to when building and deploying plugins for Qt applications.
Additional Libraries
You can check which libraries your application is linking against by using the
otool tool. To use otool , all you need to do is to run it like this:
Unlike the deployment processes on X11 and Windows, compiler specific libraries rarely have to be redistributed along with your application. But since Qt can be configured, built, and installed in several ways on Mac OS X, there are also several ways to deploy applications. Typically your goals help determine how you are going to deploy the application. The last sections describe a couple of things to keep in mind when you are deploying your application.
Mac OS X Version Dependencies
From Qt 4.6, Mac OS X 10.3 (Panther) is no longer supported. Qt 4.6 applications can be built and deployed on Mac OS X 10.4 (Tiger) and higher. This is achieved using weak linking. In weak linking, Qt tests whether a function added in a newer version of Mac OS X is available on the computer it is running on. This allows Qt to use newer features, when it runs on a newer version of OS X, while remaining compatible on the older versions.
For more information about cross development issues on Mac OS X, see Apple's Developer Website.
Since the linker is set to be compatible with all OS X versions, you must change the
MACOSX_DEPLOYMENT_TARGET environment variable to get weak linking to work for your application. You can add:
to your .pro file, and qmake will take care of this for you.
For more information about C++ runtime environment, see Apple's Developer Website
Deploying Phonon Applications on Mac OS X
Architecture Dependencies
The Qt for Mac OS X libraries, tools, and examples can be built 'universal' (i.e. they run natively on both Intel and PowerPC machines). This is accomplished by passing
-universal on the configure line of the source package, and requires that you use GCC 4.0.x. On PowerPC hardware you will need to pass the universal SDK as a command line argument to the Qt configure command. For example:
From 4.1.1 the Qt binary package is already universal.
Qt Mac Download
If you want to create a binary that runs on older versions of PowerPC and x86, it is possible to build Qt for the PowerPC using GCC 3.3, and for x86 one using GCC 4.0, and use Apple's
lipo(1) tool to stitch them together. This is beyond the scope of this document and is not something we have tried, but Apple documents it on their developer website.
Once you have a universal Qt, qmake will generate makefiles that will build for its host architecture by default. If you want to build for a specific architecture, you can control this with the
CONFIG line in your .pro file. Use CONFIG+=ppc for PowerPC, and CONFIG+=x86 for x86. If you desire both, simply add both to the CONFIG line. PowerPC users also need an SDK. For example:
Qt Creator Mac Download
Besides
lipo , you can also check your binaries with the file(1) command line tool or the Finder.
The Mac Deployment Tool
The Mac deployment tool can be found in QTDIR/bin/macdeployqt. It is designed to automate the process of creating a deployable application bundle that contains the Qt libraries as private frameworks.
The mac deployment tool also deploys the Qt plugins, according to the following rules:
Note: If you want a 3rd party library to be included in your application bundle, then you must copy the library into the bundle manually, after the bundle is created.
macdeployqt supports the following options:
© 2016 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |