Cross Compile On Linux For Mac

admin



Clang/LLVM is a cross compiler by default and is now available on nearly every Linux distribution, so we just need a proper port of the cctools/ld64 and the macOS SDK. OSXCross includes a collection of scripts for preparing the SDK and building the cctools/ld64. Real cross-compiling (building on Linux for MacOS X) This means that you have a gcc version on your Linux machine that emits executables that run on OSX. Unfortunately, OSX uses MACH-O binaries and building a cross-compiling gcc is very tricky. So I would not consider this as a reasonable option. In Linux Host for Mac Target. In this particular case we illustrate Target System = Mac; Build System = Linux; Major steps. Build your tool chain in the build system This is the set of compiler and linker that must be build in the build system, but will know how to generate code for the Target system. Create a TryRun. File in the native system.

This document contains instructions to build AVR and ARM cross compilers on Mac OS X from source packages. Note, that precompiled binaries are available in our download area.

So far, only the ARM toolchain had been tested on Leopard, running on a PPC. Be warned, that building on other OS X releases or building the AVR toolchain may not work as described.

Installing Xcode

Apple's Xcode package contains all the tools we need to build the cross toolchain. Open Terminal and enter

If the response is similar to

then GCC is already available and probably there is no need to install it again. However, if the response is

then you need to download Xcode from
developer.apple.com/tools/xcode/

A registration is required, but this is free of charge.

Leave the Terminal window open. We'll need it later on.

Download Toolchain Sources

In the Terminal window create a new directory and change to it. Feel free to use any name and create it at any place.

Now use the following commands to download the sources.

Additionally we need the C libraries, avr-libc for the AVR or newlib for the ARM platform. Get the newlib sources with

The avr-libc sources can be downloaded with

Next we unpack the sources, using

and

for the AVR library or

for the ARM library. Note the different option -xzf for the gzipped newlib. Each command takes at least several seconds to execute.

We will finally end up with 3 new subdirectories in our toolcahin folder. You may remove the downloaded archives or keep them in case you want to start all over again later on.

Build Environment Setup

The toolchain will be built in 5 steps:

  1. Building the binary utilities
  2. Building the compiler
  3. Building the libraries
  4. Rebuilding the compiler (ARM)
  5. Building the debugger

In the second step we get different results while building for AVR or ARM. For ARM targets we are building an intermediate compiler first, which is rebuilt in step 4.

The last step, building GDB, is optional and needed for in-circuit debugging only. This requires some additional tools, which are not discussed in this document.

In all steps we are going to use the same environment. Thus, once set in the Terminal window, you need to keep the window open to preserve these settings.

First we specify the target platform:

for the AVR or

for the ARM toolchain. For both targets we set

which defines the directory where the final binaries will be installed. If you prefer any different location, go ahead. Within this folder we need to create a bin directory in advance and add that to our PATH variable.

Note, that we need root authorization to access the path /usr/local, which had been stored in the variable $prefix. Thus the prepended sudo command, which will prompt you for your user password. If you chose a different location, this may not be required.

Building the Binary Utilities

GNU binutils is a collection of binary tools, which needs to be build first. As with all parts of the toolchain, we create a specific build directory inside the package's directory.

The next command, which configures the build, differs slightly among targets. For the AVR we simply use

while the ARM requires

When this went through without errors, we can start building and installing the binaries.

This will take several minutes. When done, try

to check the AVR build or

to check the ARM variant.

This should display the GNU assembler version information. If the command can't be found, check your PATH and prefix settings.

Building the Compiler

Building the ARM compiler requires a readily built library. Building the newlib library, however, requires a compiler. To solve this chicken and egg problem, we build an intermediate bootstrap compiler first, which requires the library's header files only. For the AVR, however, the final compiler is built in this step.

For both targets, create a build directory and change to it.

As expected, the configure options differ among our targets. For the AVR use

The intermediate ARM compiler is configured as follows.

Note, that we may need the sudo command to gain access to the installation directory, where the newlib header files will be copied to.

Building and installing the AVR compiler is done using the standard commands.

To build and install the intermediate ARM compiler use

Again, this will take several minutes. When done, we can use

to test the AVR compiler or

for the ARM compiler. This should display the compiler version information.

Arm Linux Cross Compile

If the build fails, you may try to exclude the C++ compiler by simply removing ,c++ from the --enable-languages option.

Building the Libraries

As stated earlier, we use avr-libc for the AVR and newlib for the ARM.

To configure the AVR build, use

Note the grave accents, acute accents will not work.

The following commands are used to configure the ARM library.

Both libraries are built with

Rebuilding the Compiler

As explained above, this step is only required when building for the ARM target.

Building the Debugger

Even if we do not have all tools available for in-circuit debugging, it is a good idea to build the GNU debugger now, so it will be available later. Here are the related commands, valid for both targets:

Stripping the Binaries

In an additional step we may strip the installed binaries to save disk space and decrease load times.

What's Next?

Now we have all tools available on our OS X machine to create firmware binaries for AVR and/or ARM target boards, either from C, C++ or assembler source code.

If you want to compile applications running on Nut/OS, you may now download the Ethernut package from the local download page.

Cross Compile Linux On Windows

Selecting a tool for uploading firmware binaries to your target board highly depends on the specific CPU and the programming adapter being used. For AVR targets, AVRDUDE is a good choice, while we recommend OpenOCD for ARM targets.

The document OpenOCD and Ethernut 3 contains additional information about installing and running OpenOCD on a Mac.

Finally you may want to set up an integrated development environment, which includes a source code editor, compiler, linker, debugger and more. If you are already familiar with Xcode, this might be the right way to go. If you are, like me, working on several different platforms, then Eclipse is probably a good choice.

External Links

dirkraffel.wordpress.com/2008/02/22/building-a-gnu-arm-cross-compiler-toolchain-on-mac-os-x/
Building a GNU ARM cross-compiler toolchain on Mac OS X.

www.nslu2-linux.org/wiki/HowTo/SetUpAToolChainOnAMac
Describes another way to set up an ARM toolchain on Mac OS X.

www.cocoamachine.com/blog/
Blog about setting up a cross development for the iPhone, which is based on an ARM CPU.

developer.apple.com/tools/xcode/
Xcode is Apple's premiere development environment for Mac OS X.

gcc.gnu.org/
Homepage of the GNU Compiler Collection.

www.gnu.org/software/binutils/
GNU Binutils' homepage.

sourceware.org/gdb/
GDB, the GNU Project Debugger.

www.eclipse.org/
An open development platform based on Java.

savannah.nongnu.org/projects/avrdude/
AVRDUDE is software for programming Atmel AVR Microcontrollers.

openocd.sourceforge.net
The Open On-Chip Debugger aims to provide debugging, in-system programming and boundary-scan testing for ARM based target devices.

< ITK
  • 1In Linux Host for Mac Target
    • 1.1Major steps
  • 2In Linux Host for Windows Target
    • 2.1Major steps
  • 3In Linux Host for ARM Target
    • 3.1Major steps

This page describes the procedure to follow when cross compiling ITK for another system.

In this page, we will refer to the system as:

  • Target System: The system where the executables are intended to run.
  • Build System: The system where the executables are built.

In this particular case we illustrate

Cross Compile On Linux For Mac
  • Target System = Mac
  • Build System = Linux

Major steps

  1. Build your tool chain in the build system
    • This is the set of compiler and linker that must be build in the build system, but will know how to generate code for the Target system.
  2. Create a TryRun ... file in the native system
    • This could be generated (as a skeleton) with the following commands

Building the ToolChain for Darwin

The following is a script developed by Johannes Schindelin (originally intended for FIJI)

Gathering Configuration settings in the target system

Following the advice of the CMake Wiki [1]

Put the following in a file called ToolChain.cmake

and run it with CMake using the command (in an empty directory)

This will generate (among many other things) a File called

Then, manually populate, the values of each one of the fields.

The values to be put in this file can be taken from the CMakeCache.txt file of a native build in Darwin.


Finally, copy this file to the build system.

Using the Configuration in the Host

Now that you have copied the TryRunResuls.cmake file to the host system, you can use it as an initial cache for configuring the build.

Do the command in the build system.

once the configuration is completed you can proceed to build ITK by simply typing

The full process scripted

The process as a whole has been scripted in the file below

Thanks to Johannes Schindelin for contributing the script.

In this particular case we illustrate

  • Target System = Windows
  • Build System = Linux

Note: the MXE project has an ITK package! Just


Major steps

  1. Build your tool chain in the build system
    • This is the set of compiler and linker that must be build in the build system, but will know how to generate code for the Target system.
    • In this case we use MinGW as the tool chain
  2. Create a TryRun ... file in the native system
    • This could be generated (as a skeleton) with the following commands

Building the ToolChain for Windows

The MXE project will build the toolchain nicely, and it even creates a CMake toolchain file.

Cross Compile On Linux For Mac Os

The following is a script developed by Johannes Schindelin (originally intended for FIJI).Script for Building the Windows (MinGW) Toolchain in Linux

Gathering Configuration settings in the target system

Following the advice of the CMake Wiki [2], put the following in a file called ToolChain.cmake

Note that if you are using MXE, it already comes with a toolchain file at

Run CMake using the command (in an empty directory)

This will generate (among many other things) a File called

The values to be put in this file can be taken from the CMakeCache.txt file of a native build in Windows. The CMakeCache.txt can be created by manually running a CMake configuration on Windows. Use this script to populate the TryRun results with the Windows CMakeCache.txt contents.

Using the Configuration in the Host

Now that you have copied the TryRunResuls.cmake file to the host system, you can use it as an initial cache for configuring the build.

Do the command in the build system.

Cross compile linux kernel

once the configuration is completed you can proceed to build ITK by simply typing

The build process will fail when trying to create the HDF5 library.

Copy the executables that were created on the host system, bin/H5detect.exe and bin/H5make_libsettings.exe to the Windows target and run them,

Then copy the results *.c files to Modules/ThirdParty/HDF5/src/itkhdf5/ in the host build tree. Restart the build,

In this particular case we illustrate

  • Target System = Raspberry Pi (ARMv6)
  • Build System = Linux (Ubuntu 12.10)

Major steps

  1. Build your tool chain in the build system
    • This is the set of compiler and linker that must be build in the build system, but will know how to generate code for the Target system.
    • In this case we use crosstool-ng to build the tool chain
  2. Create a TryRun ... file in the native system
    • This could be generated (as a skeleton) with the following commands

Building the ToolChain for ARM

  • The process is described in detail here:
  • based on the instructions from:

Gathering Configuration settings in the target system

Following the advice of the CMake Wiki [3]

Put the following in a file called ToolChain.cmake


and run it with CMake using the command (in an empty directory)

This will generate (among many other things) a File called

Then, manually populate, the values of each one of the fields.

The values to be put in this file can be taken from the CMakeCache.txt file of a native build in the Raspberry Pi.

For reference,

  • Here is a CMakeCache.txt file from a native configuration in the Raspberry Pi.
  • Here is the corresponding TryRunResults.cmake file after updating values from the Raspberry Pi.

Using the Configuration in the Host

Now that you have copied the TryRunResuls.cmake file to the host system, you can use it as an initial cache for configuring the build.

Do the command in the build system.

once the configuration is completed you can proceed to build ITK by simply typing

Dealing with TIFF bootstrapping

The build process of the TIFF library requires to first build an executable file called:

Cross Compile On Linux For Macs

  • mkg3states (renamed as itkmkg3states in ITK)

in order to generate a file called:

  • tif_fax2sm.c

Since, during the cross-compilation process we generate executables that are for a different target architecture, the itkmkg3states file that we built, can't be run in the host to generate the tif_fax2sm.c file.

One way around this is to build the executable for the architecture of the host (e.g. taking it from any other local build of ITK in the host), and use it to replace the itkmkg3states file. Then using it to generate the .c file.

This can be done with the following commands:

  • cd ITK_CROSS_COMPILED_BINARY_DIR/Modules/ThirdParty/TIFF/src/itktiff
  • cp ITK_NATIVE_BINARY_DIR/Modules/ThirdParty/TIFF/src/itktiff/itkmkg3states .
  • ./itkmkg3states -c const ITK_CROSS_COMPILED_BINARY_DIR/Modules/ThirdParty/TIFF/src/itktiff/tif_fax3sm.c

Then it is possible to continue with the 'make' process.

Packaging

Once the build finishes, we can package ITK with the command:

  • make package

this will produce three files (that are independent of each other)

  • ITK-4.4.0-Linux.sh
  • ITK-4.4.0-Linux.tar.gz
  • ITK-4.4.0-Linux.tar.Z

Cross Compile Linux Kernel

For example, copying the ITK-4.4.0-Linux.tar.gz file to the target, and expanding it there will provide a local installation of ITK against which it is possible to build ITK applications.

Cross Compile On Linux For Macbook Pro

Extra Links

How To Compile C++ Linux

Retrieved from 'https://itk.org/Wiki/index.php?title=ITK/Cross_Compiling&oldid=62200'