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.
To download and install Qt for macOS, follow the instructions on the Getting Started with Qt page.
Supported Versions
May 03, 2018 They just stop releasing updates for old versions of macOS with no announcement, and you’re on your own. This is very unusual if you’re used to dealing with Microsoft Windows. Microsoft publishes their Windows support lifecycle, which spells out precisely (and guarantees) how long each product will receive different types of updates.
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.
Now that you have the basic pieces in place, it is time to build your application. This section covers some of the more common issues that you may encounter in bringing your UNIX application to OS X. These issues apply largely without regard to what type of development you are doing.
Using GNU Autoconf, Automake, and Autoheader
If you are bringing a preexisting command-line utility to OS X that uses GNU
autoconf , automake , or autoheader , you will probably find that it configures itself without modification (though the resulting configuration may be insufficient). Just run configure and make as you would on any other UNIX-based system.
If running the
configure script fails because it doesn’t understand the architecture, try replacing the project’s config.sub and config.guess files with those available in /usr/share/automake-1.6 . If you are distributing applications that use autoconf, you should include an up-to-date version of config.sub and config.guess so that OS X users don’t have to do anything extra to build your project.
If that still fails, you may need to run
/usr/bin/autoconf on your project to rebuild the configure script before it works. OS X includes autoconf in the BSD tools package. Beyond these basics, if the project does not build, you may need to modify your makefile using some of the tips provided in the following sections. After you do that, more extensive refactoring may be required.
![]()
Some programs may use autoconf macros that are not supported by the version of autoconf that shipped with OS X. Because autoconf changes periodically, you may actually need to get a new version of autoconf if you need to build the very latest sources for some projects. In general, most projects include a prebuilt
configure script with releases, so this is usually not necessary unless you are building an open source project using sources obtained from CVS or from a daily source snapshot.
However, if you find it necessary to upgrade autoconf, you can get a current version from http://www.gnu.org/software/autoconf/. Note that autoconf, by default, installs in
/usr/local/ , so you may need to modify your PATH environment variable to use the newly updated version. Do not attempt to replace the version installed in /usr/ .
For additional information about using the GNU autotoolset, see http://autotoolset.sourceforge.net/tutorial.html and the manual pages
autoconf , automake , and autoheader . https://clevercloud512.weebly.com/pavtube-video-converter-for-mac-free-download.html.
Compiling for Multiple CPU Architectures
Because the Macintosh platform includes more than one processor family, it is often important to compile software for multiple processor architectures. For example, libraries should generally be compiled as universal binaries even if you are exclusively targeting an Intel-based Macintosh computer, as your library may be used by a PowerPC binary running under Rosetta. For executables, if you plan to distribute compiled versions, you should generally create universal binaries for convenience.
![]()
Software to take picture on mac of. When compiling programs for architectures other than your default host architecture, such as compiling for a ppc64 or Intel-based Macintosh target on a PowerPC-based build host, there are a few common problems that you may run into. Most of these problems result from one of the following mistakes: Hp scanner printer upgrades and downloads for macos mojave.
Whenever cross-compiling occurs, extra care must be taken to ensure that the target architecture is detected correctly. This is particularly an issue when generating a binary containing object code for more than one architecture.
In many cases, binaries containing object code for more than one architecture can be generated simply by running the normal configuration script, then overriding the architecture flags at compile time.
For example, you might run
followed by
Macos Compile For Older Version Windows 7
to generate a universal binary (for Intel-based and PowerPC-based Macintosh computers). To generate a 4-way universal binary that includes 64-bit versions, you would add
-arch ppc64 and -arch x86_64 to the CFLAGS and LDFLAGS .
Note: If you are using an older version of gcc and your makefile passes
LDFLAGS to gcc instead of passing them directly to ld, you may need to specify the linker flags as -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk . This tells the compiler to pass the unknown flags to the linker without interpreting them. Do not pass the LDFLAGS in this form to ld, however; ld does not currently support the -Wl syntax.
If you need to support an older version of gcc and your makefile passes
LDFLAGS to both gcc and ld, you may need to modify it to pass this argument in different forms, depending on which tool is being used. Fortunately, these cases are rare; most makefiles either pass LDFLAGS to gcc or ld, but not both. Newer versions of gcc support -syslibroot directly.
If your makefile does not explicitly pass the contents of
LDFLAGS to gcc or ld , they may still be passed to one or the other by a make rule. If you are using the standard built-in make rules, the contents of LDFLAGS are passed directly to ld . If in doubt, assume that it is passed to ld . If you get an invalid flag error, you guessed incorrectly.
If your makefile uses gcc to run the linker instead of invoking it directly, you must specify a list of target architectures to link when working with universal binary object (.o) files even if you are not using all of the architectures of the object file. If you don't, you will not create a universal binary, and you may also get a linker error. For more information about 64-bit executables, see 64-Bit Transition Guide.
However, applications that make configuration-time decisions about the size of data structures will generally fail to build correctly in such an environment (since those sizes may need to be different depending on whether the compiler is executing a
ppc pass, a ppc64 pass, or an i386 pass). When this happens, the tool must be configured and compiled for each architecture as separate executables, then glued together manually using lipo .
In rare cases, software not written with cross-compilation in mind will make configure-time decisions by executing code on the build host. In these cases, you will have to manually alter either the configuration scripts or the resulting headers to be appropriate for the actual target architecture (rather than the build architecture). In some cases, this can be solved by telling the configure script that you are cross-compiling using the
--host , --build , and --target flags. However, this may simply result in defaults for the target platform being inserted, which doesn’t really solve the problem.
The best fix is to replace configure-time detection of endianness, data type sizes, and so on with compile-time or run-time detection. For example, instead of testing the architecture for endianness to obtain consistent byte order in a file, you should do one of the following:
Similarly, instead of performing elaborate tests to determine whether to use
int or long for a 4-byte piece of data, you should simply use a standard sized type such as uint32_t .
Note: Not all script execution is incompatible with cross-compiling. A number of open source tools (GTK, for example) use script execution to determine the presence or absence of libraries, determine their versions and locations, and so on.
https://trustever451.weebly.com/virtual-audio-cable-for-mac-download.html. In those cases, you must be certain that the info script associated with the universal binary installation (or the target platform installation if you are strictly cross-compiling) is the one that executes during the configuration process, rather than the info script associated with an installation specific to your host architecture.
There are a few other caveats when working with universal binaries:
For additional information about autoconf, automake, and autoheader, you can view the autoconf documentation at http://www.gnu.org/software/autoconf/manual/index.html.
For additional information on compiler flags for Intel-based Macintosh computers, modifying code to support little-endian CPUs, and other porting concerns, you should read Universal Binary Programming Guidelines, Second Edition, available from the ADC Reference Library.
Cross-Compiling a Self-Bootstrapping Tool
Probably the most difficult situation you may experience is that of a self-bootstrapping tool—a tool that uses a (possibly stripped-down) copy of itself to either compile the final version of itself or to construct support files or libraries. Some examples include TeX, Perl, and gcc.
Ideally, you should be able to build the executable as a universal binary in a single build pass. If that is possible, everything “just works”, since the universal binary can execute on the host. However, this is not always possible. If you have to cross-compile and glue the pieces together with
lipo , this obviously will not work.
If the build system is written well, the tool will bootstrap itself by building a version compiled for the host, then use that to build the pieces for the target, and finally compile a version of the binary for the target. In that case, you should not have to do anything special for the build to succeed.
In some cases, however, it is not possible to simultaneously compile for multiple architectures and the build system wasn’t designed for cross-compiling. In those cases, the recommended solution is to pre-install a version of the tool for the host architecture, then modify the build scripts to rename the target’s intermediate copy of the tool and copy the host’s copy in place of that intermediate build product (for example,
mv miniperl miniperl-target; cp /usr/bin/perl miniperl ).
By doing this, later parts of the build script will execute the version of the tool built for the host architecture. Assuming there are no architecture dependencies in the dependent tools or support files, they should build correctly using the host’s copy of the tool. Once the dependent build is complete, you should swap back in the original target copy in the final build phase. The trick is in figuring out when to have each copy in place.
Conditional Compilation on OS X
You will sometimes find it necessary to use conditional compilation to make your code behave differently depending on whether certain functionality is available.
Older code sometimes used conditional statements like
#ifdef __MACH__ or #ifdef __APPLE__ to try to determine whether it was being compiled on OS X or not. While this seems appealing as a quick way of getting ported, it ultimately causes more work in the long run. For example, if you make the assumption that a particular function does not exist in OS X and conditionally replace it with your own version that implements the same functionality as a wrapper around a different API, your application may no longer compile or may be less efficient if Apple adds that function in a later version.
Apart from displaying or using the name of the OS for some reason (which you can more portably obtain from the
uname API), code should never behave differently on OS X merely because it is running on OS X. Code should behave differently because OS X behaves differently in some way—offering an additional feature, not offering functionality specific to another operating system, and so on. Thus, for maximum portability and maintainability, you should focus on that difference and make the conditional compilation dependent upon detecting the difference rather than dependent upon the OS itself. This not only makes it easier to maintain your code as OS X evolves, but also makes it easier to port your code to other platforms that may support different but overlapping feature sets.
The most common reasons you might want to use such conditional statements are attempts to detect differences in:
Instead it is better to figure out why your code needs to behave differently in OS X, then use conditional compilation techniques that are appropriate for the actual root cause.
The misuse of these conditionals often causes problems. For example, if you assume that certain frameworks are present if those macros are defined, you might get compile failures when building a 64-bit executable. If you instead test for the availability of the framework, you might be able to fall back on an alternative mechanism such as X11, or you might skip building the graphical portions of the application entirely.
For example, OS X provides preprocessor macros to determine the CPU architecture and byte order. These include:
In addition, using tools like
autoconf , you can create arbitrary conditional compilation on nearly any practical feature of the installation, from testing to see if a file exists to seeing if you can successfully compile a piece of code.
For example, if a portion of your project requires a particular application framework, you can compile a small test program whose
main function calls a function in that framework. If the test program compiles and links successfully, the application framework is present for the specified CPU architecture.
You can even use this technique to determine whether to include workarounds for known bugs in Apple or third-party libraries and frameworks, either by testing the versions of those frameworks or by providing a test case that reproduces the bug and checking the results.
For example, in OS X,
poll does not support device files such as /dev/tty . If you just avoid poll if your code is running on OS X, you are making two assumptions that you should not make:
A better solution is to use a configuration-time test that tries to use
poll on a device file, and if the call fails, disables the use of poll . If using poll provides some significant advantage, it may be better to perform a runtime test early in your application execution, then use poll only if that test succeeds. By testing for support at runtime, your application can use the poll API if is supported by a particular version of any operating system, falling back gracefully if it is not supported.
A good rule is to always test for the most specific thing that is guaranteed to meet your requirements. If you need a framework, test for the framework. If you need a library, test for the library. If you need a particular compiler version, test the compiler version. And so on. By doing this, you increase your chances that your application will continue to work correctly without modification in the future.
Choosing a Compiler
OS X ships two compilers and their corresponding toolchains. The default compiler is based on GCC 4.2. In addition, a compiler based on GCC 4.0 is provided. Older versions of Xcode also provide prior versions. Compiling for 64-bit PowerPC and Intel-based Macintosh computers is only supported in version 4.0 and later. Compiling 64-bit kernel extensions is only supported in version 4.2 and later.
Always try to compile your software using GCC 4 because future toolchains will be based on GCC version 4 or later. However, because GCC 4 is a relatively new toolchain, you may find bugs that prevent compiling certain programs.
Use of the legacy GCC 2.95.2-based toolchain is strongly discouraged unless you have to maintain compatibility with OS X version 10.1.
If you run into a problem that looks like a compiler bug, try using a different version of GCC. You can run a different version by setting the
CC environment variable in your Makefile. For example, CC=gcc-4.0 chooses GCC 4.0. In Xcode, you can change the compiler setting on a per-project basis or a per-file basis by selecting a different compiler version in the appropriate build settings inspector.
Setting Compiler Flags
When building your projects in OS X, simply supplying or modifying the compiler flags of a few key options is all you need to do to port most programs. These are usually specified by either the
CFLAGS or LDFLAGS variable in your makefile, depending on which part of the compiler chain interprets the flags. Unless otherwise specified, you should add these flags to CFLAGS if needed.
Note: The 64-bit toolchain in OS X v10.4 and later has additional compiler flags (and a few deprecated flags). These are described in more detail in 64-Bit Transition Guide.
Some common flags include:
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |