Omaticblog920

1. Compile Qt From Source
2. Cross Compile Qt For Raspberry Pi
3. Cross Compile Qt For Mac Shortcut

In my previous posts, I came to the realization that the Raspberry Pi is not very fast! This results lots of chair spinning time while waiting for my projects to compile. A

• Cross Compiling QT for ARM from Linux. As much as I would have liked, this is impossible (or nearly so, I couldn't make it work) from the Mac. The reason seems to be that the configure scripts for QT are quite insistent on building some Mac stuff (as they should), but the relevant distribution for Mac does not have the correct codes for cross compiling and the distribution for cross compiling.
• I have actually used it on Linux to cross-compile for S/390 a while back, and also to cross-compile ARM code on a Power Mac (I used the instructions here to set it up). That said, I think that what you want is to cross-compile Windows x64 on a 32 bit virtual machine running Windows. Hello @NimmiVidya, Qt support cross-platform software development.
• Qt is the best cross-platform tool for mobile app development. Why I’m counting this tool in the best cross-platform tools is because of its quality features that allow creating fluid, UIs, applications, and embedded devices with the same code for Android, iOS, and Windows.

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. Qt for macOS - Deployment; Note: For selling applications in the macOS App Store, special rules apply. In order to pass validation, the.

After I did some brief research, I came across crosstool-ng. It enagbles anyone to create a toolchain to compile Raspberry Pi code directly on a (much faster) Macbook.

If you are unfamiliar with the process of compiling a toolchain on your own computer, let me be frank: it’s not fun.

Luckily, with this post you can get yours working in no time.

Update 8/29/16: I have updated this tutorial in several places for newer systems. I’m currently running a Macbook Pro with 10.11.6.

Note 8/29: This tutorial now is focused on the Raspberry Pi 3 B. Steps can be tweaked to account for older Pis

So without further ado lets do this thing.

Before we get started

Before we start anything I recently compiled the toolchain for RPi3. It will save you a whole bunch of time to download it here rather than go through this procedure.

These files include:

• Linux Kernel: 4.3

• hardfp: yes

• arch: armv8-a

• proc: cortex-a53

• glibc 2_22

• gcc 5.2.0

• binutils 2.25.1

• gdb 7.10

• gmp 6.0.0

• mpfr 3.1.3

• mpc 1.0.3

For those who want to continue for giggles, by all means…

Install Homebrew

You will need Hombrew to install some dependencies. If you haven’t already installed it you can run the command below:

Install crosstool-ng

Note: a few other dependencies get installed when crosstool-ng is compiled. Be prepared to wait a little while everything assembles.

Install gettext

Note: this is more of a precaution then a requirement. I believe by the end of this process that this was not necessary for getting crosstool-ng to work.

Create two case-sensitive disk images

Open up Disk utility. Click on the New Image button.

1. You need a disk at least 15GB in size. This will house all the source code and object files when all said and done.

2. The next disk can be exactly the same but only 250MB in size. (When fully compiled and compressed everything turned out to be around 107MB)

Note 8/29: for some reason there is a bug on OSX which prevents you from formating a case sensitive drive in Disk Utility. So create a non-case sensitive image and format it to a case sensitive one. The file system needs to be case sensitive.

Note* 8/29: Also, should you make a disk that is not the correct size, you can invoke the resize command to fix it!

Install GNU grep

Crosstools relies on the use of GNU grep. The grep built with OSX is not 100% exactly the same. So, let’s build it!

Note 8/29: this now can be done while installing crosstool-ng using the --with-grep option.

Edit paths.sh file

My paths.sh file was located here:

I changed the grep line from:

To:

Note 8/29: likely can be avoided with the note above. You can also edit your .bash_profile to temporarily set which grep to use

Load the Linux/GNU option

This will load a general Linux/GNU config. We’ll end up replacing the config but it gives us a good starting point.

Note 8/29: this is a better starting point than my original suggestion. The config file below will change the remaining settings to accomodate for the different processor.

Install config file

Download the config file here.

You will have to copy it to your case sensitive disk image and rename it to .config.

Modify the config file

Run the following in your working directory.

Change the following as needed. Note: This only needs to be changed if you change the names of the .dmg images.

Paths and misc options

Note: all of these are under the ** Paths ** section.

• Local tarballs directory

  I used /Volumes/xtools-build-env/src. Make sure you set yours to your setup.

• Working directory

  I used /Volumes/xtools-build-env/.build. Make sure you set yours to your setup.

• Prefix directory

  I used /Volumes/xtools/${CT_TARGET}. Make sure you set yours to your setup.

Note: the next few settings are under the ** Extracting ** section.

• Stop after extracting tarballs

  This option should be checked.

• Parallel jobs

  Note 8/29: new version already has this value set. You can leave it be.

Download and extract the packages

Run the following command:

The build command will stop after extracting all the sources.

Change source file

In ./.build/src/binutils-2.25.1/gold/gold-threads.cc you will need to change the file at line 284. Here is the before and after code blocks:

Change it to:

Update the ulimit

Ulimit controls the amount of resources allowed by a shell instance. In this case we need to increase this limit in order to prevent compilation errors.

Undo some the extract only config option

Undo one of the config settings we changed earlier. Open up:

Paths and misc options.

Note: the next few settings are under the ** Extracting ** section.

• Stop after extracting tarballs

  This option should be unchecked.

Compile Qt From Source

Begin the build!

Run:

Play the waiting game

Depending on how fast your setup is it may take a few hours to compile fully. If you’re impatient you can always get the binaries I just compiled here

In the end

By the time it’s done doing its thing you should have a fully capable cross platform toolchain for the Raspberry Pi! (Woot) An easy way to test it is to do the following:

(Hit ctrl-d to escape)

Copy test over to your Raspberry Pi.

Then ssh in and run the test executable

Other Notes

New notes as of 8/29 are as follows:

STOP/RESTART Crosstools now has a nifty stop and restart feature. Should a build break on a particular sub-component, you can actually fix the issue and continue the build from where it broke. It saves a ton of time. In order to take advantage of the feature you need to enable CT_DEBUG_CT_SAVE_STEPS in your .config

Then you can invoke the STOP or RESTART command:

ct-ng list-stepsct-ng build RESTART=cc_core_pass_1

Building Static Becuase OSX does not build based on static libraries we need to make sure those options are disabled. This is already done in my config file but for those who are interested here are the flags:

Thank you to Rolando for posting this in the comments!

Many thanks

I used several blog posts and articles over the web to get this to work. Many thanks to their previous efforts.

Last Modified: 2020.3.7

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

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.

Cross Compile Qt For Raspberry Pi

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_ARCHSqmake 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: Angelbird wrk for mac ssd.

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).

Cross Compile Qt For Mac Shortcut

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 Overviews - list of topics about application development
• Examples and Tutorials - code samples and tutorials
• Qt Reference Pages - a listing of C++ and QML APIs

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.