Infinite Horizon Image

Download

Mac OS X Cross Toolchain FAQS

 


 

What code foundation is used to build the Mac OS X cross-compiler toolchains?

We have very positive experiences using Mentor Graphics Sourcery Lite toolchains (formerly Codesourcery) in our own embedded development efforts.  In our opinion, these are some of the best products on the market from both a capability and stability standpoint for Windows and Linux hosts.  Unfortunately Mentor Graphics does not currently provide native toolchain builds for the Mac OS X environment.  Nevertheless, we think so highly of their products for Linux that we build our internal Mac OS X tools from their very robust source distributions.  As a way of giving back to the open-source community and recognizing the heritage of Sourcery toolchains in the world of embedded development, we are now making our internal Mac OS X cross-compiler toolchain builds for ARM available to the general public for free.

 

How frequently are the Mac cross-compiler toolchains updated and how are they identified?

Mentor Graphics typically updates their Sourcery tools approximately twice a year, typically in the spring and fall.  Our plans are to create Mac OS X updates in the future reasonably aligned to their releases.  Unlike Mentor Graphics, we are not in the business of toolchain development and can only work on these activities as time allows.  In some cases this may result in time lag between their releases and ours.  To make it clear which version of the toolchains are available, we use the same revision nomenclature they do to make association easy.

 

What type of cross-compiler toolchains are available for Mac OS X and what should I download?

Most of our development work relying on open-source toolchains utilizes processors from the ARM family.  Consequently we use both the bare-metal ARM EABI and ARM GNU/Linux toolchains.  If you are trying to build an application for an environment without an operating system or attempting to build the Linux kernel itself, you will need the EABI toolchain.  If you need to build a user-space application that will run under Linux, use the GNU/Linux toolchain since that provides the correct linker scripts and hooks for the application to properly execute under Linux.  The GNU/Linux toolchain also provides a version of the GDB server that is specifically targeted for remote user-space debugging.

 

Are there any plans to eventually make binary packages available for other targets?

For the near term, no.  Toolchains are a necessary evil in our business rather then the business itself.  We currently do not have any client development efforts that depend on other target architectures.  If circumstances change and we develop additional targets to meet an unmet business need, we would eventually make them publicly available for download also.

 

Are the build configurations identical to native Mentor Graphics Sourcery Lite packages?

While Mac OS X and Linux are similar, there are subtle host library differences in the Apple BSD framework that require additional patches and tweaks during the build process.  Nevertheless, the Mac OS X binaries generally attempt to mirror as closely as possible most of the same configuration options that Mentor Graphics uses to produce their native Sourcery Lite binaries.

 

Are the proprietary Mentor Graphics Sourcery components included in Mac OS X binary packages?

Unfortunately no.  Certain components that Mentor Graphics provide free with their own native Sourcery Lite binaries -- particularly those related to CS3 libraries, debug sprites, and documentation -- are subject to the terms of their license which prohibits redistribution by third-parties.  As such, we can not legally bundle those components with our packages.  If you require any of these components, you will have to obtain and install them independently.  Each Mac OS X build has a difference file saved in the base cross-compiler directory folder with the suffix "{build version}-mentor-graphics-sourcery-difference-file-map.txt" after installation that specifically outlines how the Mac OS X build differs from its corresponding Mentor Graphics Linux Sourcery binary.

 

Is it possible to do without the proprietary Mentor Graphics Sourcery components?

Yes. The single most important component found in the native Sourcery tools is the CS3 libraries for bare-metal targets which contains pre-packaged startup and exception vectors/handlers for a broad spectrum of processors.  With the datasheet for a particular processor in hand, you can usually write your own handlers fairly quickly.

 

Why am I getting linker errors for missing 'sbrk', 'fstat', 'read', 'lseek' and other functions?

These errors are NOT THE RESULT OF A COMPILER BUG when using any bare-metal EABI compiler!  These functions rely on knowledge of the size and allocation of heap memory available on the target hardware.  Consequently they are not static universal functions applicable to any and all hardware.  If you are working with a new target where someone has not already performed this activity, you will need to create stubs and populate them with appropriate code.

 

Is it possible to build custom Mac OS X cross-compiler toolchains?

Yes, but it takes some considerable patience and time.  To help make the process a little more straight-forward, the scripts and additional patches (if applicable) we created to build our packages are made available with the binaries.  The source tarballs are not included since these can be directly obtained from Mentor Graphics.  Needless to say, you will likely have to spend a decent amount of time also making and installing a multitude of additional support tools not normally part of the Apple Developer Tool Suite on your build host to make the build script function correctly.  Please keep in mind that if you use these scripts to build your own custom toolchains, you must remove any reference of "Carlson-Minot" from configuration information that embeds in the new binaries.

 

Are these embedded cross-compiler toolchains built as universal binaries?

Starting with the Lion OS upgrade, Apple has largely dropped support for PPC.  Given this reality and the declining base of older PPC-based machines, only the i386 and x86_64 host machine architectures will be supported moving forward.

 

Can the Eclipse IDE be used with these toolchains for a completely native Mac development?

Yes.  For a bare-metal example using Eclipse refer to application note AN103.  Keep in mind this application note demonstrates a more complex situation where most of the tools are native to Mac OS X with the exception of certain proprietary programming tools made only available by the processor manufacturer for non-Mac hosts.  In most of our internal projects proprietary tools are largely the exception.  The majority of our development projects are managed exclusively under Mac OS X.

 

Why does the Mac OS X native package installer require administrator access?

With the prevalence of malware and spyware in the world, that question is certainly legitimate.  Rest assured the installer is not up to anything nefarious.  All the files needed for the toolchain are written to '/usr/local/carlson-minot/crosscompilers'.  On most systems, root owns the base directory necessitating administrator permissions to write to it.  A person utilizing the tarball version of the appliance installing manually runs into the same issue.  That situation obviously requires 'sudo' or the administrator user account to achieve the same result.

 

How are the embedded cross-compiler toolchains for Mac OS X uninstalled?

Simply delete the '/usr/local/carlson-minot/crosscompilers' directory on the host computer.  This will revert the host to its original configuration since no files are written anywhere else.  Keep in mind this method will remove all installed cross-compilers, however, since they share a common directory.  If you desire only to remove a particular version, you can either selectively delete sub-directories manually or remove the entire directory and reinstall the desired toolchain version(s).

 

What additional support exists?

Like any free product, these tools are "as-is" and therefore lack any guarantee of support or warranty.  In the most cases, they will likely work well for most applications without any effort on your part.  If you do find issues, have general comments, or would like to make suggestions, please feel free to send them to This email address is being protected from spambots. You need JavaScript enabled to view it. .  Please understand that we may not be able to respond to all queries or take immediate action.