Since Apple only ships SDK 10.6 with Xcode4, developing PPC applications with Xcode4 became impossible. While it is possible to develop applications with Xcode4 that can also run on 10.5 and maybe even on 10.4 systems (by selecting SDK 10.6, but deployment target 10.5 or 10.4), they will only run on Intel Macs because you need at least SDK 10.5 for building PPC applications.
Further there are some rare cases, where you really need to build against an SDK prior to 10.6 for full platform support, e.g. if certain deprecated functionality has vanished completely from the 10.6 SDK, but you'll have to use it and dynamic linking is not always the best option in those cases. Also linking against an earlier SDK sometimes will ease development as functionality you are not supposed to use, as it would cause incompatibility to earlier OS versions, won't be available and any attempt to use it anyhow immediately leads to compiler or linker errors.
Last but not least Apple has also removed GCC 4.0 support from Xcode4, which may be necessary for certain software to build correctly and Apple has never allowed to compile software with GCC 4.2 when using SDK 10.4, even though I hardly believe that this would really cause any issues, after all software built with GCC 4.2 and SDK 10.6 can also run on Mac OS 10.4 without any issues as long as the deployment target has been set correctly and no functionality that is unavailable under MacOS 10.4 has been used.
Of course you can always have a parallel installation of Xcode3 next to Xcode4, but that means you must forgo all the (great?) new features of Xcode4 and keep working with the outdated Xcode3 IDE. It would certainly be much better if you could also manage all your old projects within the same IDE as your new ones and benefit from any new features available. Not all projects can be made 10.6 or Intel only in the foreseeable future. Further I'm strictly against abolishing support for older platforms earlier than would be really necessary.
Can we restore this functionality to Xcode4?
The quick answer is: Yes, we can!
Before I get to the "how it is done" part, here are some notes about my patch/hack/fix. Right from the start the major goals have been:
Keep all modifications to an absolute minimum.
We want to keep the Xcode setups as original as possible.
By all means, try to avoid patching or modifying any files.
We want all files to stay untouched and keep their original content.
Try to avoid moving or copying files around, unless absolutely necessary.
I was able to keep all those goals. Almost everything is done by creating symlinks. Only a single existing symlink had to be replaced and we'll back it up before replacement, just in case.
If you are no expert on terminal operations, I strongly advise you to copy/paste all terminal commands from my reply to your terminal, to avoid typos. Bear in mind that even spacing, quoting and especially capitalization can be important. Copy/paste them line by line, never more than one line at once and hit return after each pasted line to execute the command. Should any operation ever prompt you for a password, this will be the password of the currently logged in administrator user (your keystrokes are not displayed while typing, this is normal, don't worry, just keep typing the password and hit return; re-try if you had a typo and get prompted again).
Prerequisite
Before we can start, make sure the following conditions are true:
You are logged in as an administrator user.
You have started Terminal.app (Applications/Utilities) and a terminal window is open.
You have a copy of the Xcode3 (e.g. 3.2.5) and Xcode4 disk image (DMG) or installer available.
If you already have either Xcode version installed, consider uninstalling it first, so you can start with a fresh/clean setup. Uninstalling Xcode will not remove your preferences, color scheme or key binding customizations. Ideally you'd start with a system that has no Xcode version (neither 3 nor 4) currently installed.
Step 1: Installing Xcode3
Important: Do not install "System Tools" or "Unix Development" package of Xcode3.
Whether you want to install "Mac OS X 10.4 SDK" and/or "Documentation" is up to you. If that is a Xcode3 with iOS SDKs, whether you install those or not is also up to you.
You are free to choose any destination folder for your installation. For this guide I have chosen "/Xcode3", but feel free to pick a different one. Just make sure to alter all terminal commands accordingly.
The order of the steps given here is usually not really important, but I strongly advise you to not swap step 1 and step 2. Xcode always installs a couple of files outside of the chosen destination folder and trust me, in the end you want the Xcode4 versions of those files on your disk. By installing Xcode3 before Xcode4, you can be sure that Xcode4 will overwrite those files if necessary. I once swapped steps 1 and 2 and in the end I had some rather strange issues that might have been related to the incorrect order (I cannot say for sure, but after re-installing in the correct order the issues were gone).
Step 2: Installing Xcode4
Chose any packets you like. Installing "System Tools" is advisable, but not strictly necessary (though most people will sooner or later miss that functionality).
Again, feel free to pick any target folder you like. For this guide I chose the normal target folder "/Developer", if you take a different one, alter all terminal commands accordingly.
Step 3: Restoring 10.4/10.5 SDK Support
Switch to your terminal window and run the following commands:
cd /Developer/SDKs
sudo ln -s /Xcode3/SDKs/MacOSX10.4u.sdk .
sudo ln -s /Xcode3/SDKs/MacOSX10.5.sdk .
Of course only run the command for 10.4u if you also installed SDK 10.4 in step 1.
This is enough to bring the SDKs 10.5 (and possibly 10.4) back to the selection list in Xcode4. Give it a try if you like. Fire up Xcode4, open a project, try changing the selected SDK. That was easy, huh? Be sure to close Xcode4 again (the application, not just the window) before proceeding with the next step.
Step 4: Restoring GCC 4.0 Support
If you have not installed MacOS 10.4 SDK or if you don't plan to ever use it, you can safely skip this step and proceed with step 5.
To use SDK 10.4, you'll have to use GCC 4.0, GCC 4.2 won't work. Apple claims that GCC 4.2 is not compatible with SDK 10.4, well, if you ask me, this is a hoax. I have already overwritten this limitations more than once and there was never the tiniest issue because of it. It would be easy to modify SDK 10.4 so that Xcode will allow you to use GCC 4.2 for it, but my goal was to avoid all file modifications, so we just add GCC 4.0 support back to Xcode, which is also a good thing, because some projects really depend on GCC 4.0 (e.g. there are some bugs in GCC 4.2 that prevent valid inline assembly code to compile without errors, while the same code compiles flawlessly on GCC 4.0 and GCC 4.4).
Back to terminal:
cd /Developer/usr/bin
sudo ln -s /Xcode3/usr/bin/*4.0* .
cd /Developer/usr/libexec/gcc/powerpc-apple-darwin10
sudo ln -s /Xcode3/usr/libexec/gcc/powerpc-apple-darwin10/4.0.1 .
Right now we have restored full GCC 4.0 support except for the fact that GCC 4.0 is still not selectable in Xcode4. That is because Xcode4 has no GCC 4.0 compiler plug-in any longer. Fortunately the Xcode3 plug-in also works in Xcode4, only the position has radically changed. Apple now hides those plug-ins deep within a bundle and only plug-ins there seem to work, placing them to their old position seems to have no effect.
cd /Developer/Library/Xcode/PrivatePlugIns
cd Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins
sudo ln -s "/Xcode3/Library/Xcode/Plug-ins/GCC 4.0.xcplugin" .
Now fire up Xcode4 again, open a project and try selecting the compiler. You should have GCC 4.0 back on the list. Now you can actually already select SDK 10.4 or 10.5, GCC 4.0 and you should have no issue to build a PPC binary. Just select "Other..." for the "Architecture" build setting and manually enter "ppc", then alter "Valid Architectures" to also include "ppc". We are almost done, except that trying to build a PPC binary using GCC 4.2 and SDK 10.5 will still fail.
Step 5: Restoring PPC Support for GCC 4.2
Since Apple is only supporting Intel platforms in Xcode4, not all GCC 4.2 tools have been built with PPC support. There is one important tool that has no PPC support, the tool is named "as" and it is the GNU Assembler. To compile ppc/ppc64 binaries with GCC 4.2 we need to use an "as" version with ppc/ppc64 support. This is the one and only file (actually it also a symlink) we have to first move aside (making a backup copy) before we can replace it by a symlink:
cd /Developer/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1
sudo mv as as.bak
sudo ln -s /Xcode3/usr/bin/as .
Step 6: There is No Step 6
That's all folks. Considering how easy that was, you can imagine that Apple has certainly not dropped SDK 10.4/10.5 or ppc/ppc64 or GCC 4.0 support because this was a necessity, they dropped all that because they wanted to drop it.
I hope this setup works as well for you as it does for me. I have been able to compile all my old projects in Xcode4 without any major changes, except for having to alter a search path here and there.
PS:
It may look strange that I answer my own question here, but since I have found out how to solve this problem all by myself, I'd like to share my knowledge with the community, because I believe this is really valuable input to all MacOS developers out there. This question has been asked so many times in so many places and so far I have never seen anyone coming up with a similar fix. Share the wealth, spread the knowledge and so on, you know what I mean.
If You Still Have Issues/Questions:
If you have additional questions regarding this topic or if you still have problems to build your old projects correctly, please do what Stack Overflow has been designed for: Click on "Ask Question" in the upper right corner of this page and create a new question. That way the whole community can help you solving those issues, since the issues may not directly (maybe not even indirectly) be related to this hack.
I would recommend you mention the fact that you did apply this hack at the very beginning of your question. Maybe you even want to directly link to this question, so that people, who never heard of this hack, can easily look it up. Otherwise most people will get rather confused when you mention SDK 10.4/10.5, PPC or GCC 4.0 in combination with Xcode4, which officially supports neither of these. You might get rather stupid comments instead of decent replies if you forget to mention this hack.
Please refrain from posting your questions or issues here either as replies or as comments. Posting them as replies makes no sense because they are no replies and there is no way how people can reply back to you, other then using comments, and comments may not offer enough room for a decent reply to your question or a decent solution to your problem. And posting them as comments means you are limited to very little room and tracking reply comments will be hard as comments have no tree-like hierarchy (further they will still offer to little room for decent replies/solutions). Thank you.
Of course other kind of comments as well as better replies to the original question are always welcome ;-)
Another easy way with only Xcode4, Xcode3 is no longer needed.
$ sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gcc/darwin/ppc /Developer/usr/libexec/gcc/darwin
$ sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gcc/darwin/ppc /usr/libexec/gcc/darwin
EDITS:
For Xcode 4.1,
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gcc/darwin/ppc /Developer/usr/libexec/gcc/darwin
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gcc/darwin/ppc /usr/libexec/gcc/darwin
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/powerpc-apple-darwin10-cpp-4.2.1 /usr/bin/powerpc-apple-darwin11-cpp-4.2.1
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/powerpc-apple-darwin10-gcc-4.2.1 /usr/bin/powerpc-apple-darwin11-gcc-4.2.1
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/powerpc-apple-darwin10-g++-4.2.1 /usr/bin/powerpc-apple-darwin11-g++-4.2.1
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/powerpc-apple-darwin10-cpp-4.2.1 /Developer/usr/bin/powerpc-apple-darwin11-cpp-4.2.1
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/powerpc-apple-darwin10-gcc-4.2.1 /Developer/usr/bin/powerpc-apple-darwin11-gcc-4.2.1
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/powerpc-apple-darwin10-g++-4.2.1 /Developer/usr/bin/powerpc-apple-darwin11-g++-4.2.1
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/powerpc-apple-darwin10 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc
You can use gcc-4.2 only for PowerPC. And “-isysroot /Developer/SDKs/MacOSX10.6.sdk” option is required, because 10.7 SDK doesn't support PowerPC any more.
I've gathered together all the information from this page, Mac OS X Hints, splhack.org, and the other sources cited here, and put together a set of BASH scripts which automate the process of restoring PPC and GCC 4.0 support using either an XCode 3 installation or just XCode 4's own iPhone platform files.
As always, use with caution! and please contribute any fixes or improvements. These scripts have only been tested on my own system as of this posting.
You can download them from GitHub:
https://github.com/thinkyhead/Legacy-XCode-Scripts
If you want gcc to work from the command line as well, (as well as the above) you'll also need to:
cd /usr/libexec/gcc/powerpc-apple-darwin10/4.2.1
sudo mv as as.bak
sudo ln -s /Xcode3/usr/bin/as .
This still works with Xcode 4.3.2 from the AppStore - the version where everything is self-contained in an App bundle. As in the original hint, install Xcode 3.2.6 first* and then download Xcode 4 from the AppStore.
Then do the following symlink magic:
cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
ln -s /Developer/Xcode3.2.6/SDKs/MacOSX10.5.sdk .
cd /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/bin/
ln -s /Developer/Xcode3.2.5/usr/llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-g* .
mv powerpc-apple-darwin10-llvm-gcc-4.2 powerpc-apple-darwin11-llvm-gcc-4.2
mv powerpc-apple-darwin10-llvm-g++-4.2 powerpc-apple-darwin11-llvm-g++-4.2
The last two lines rename darwin10 to darwin11 in the symlink - I'm guessing future versions of OS X will require this to be updated as appropriate.
To install Xcode 3.2.x on Lion, mount the Xcode disk image, open Terminal, enter the commands (using bash, or the equivalent commands if you've changed your default shell):
export COMMAND_LINE_INSTALL=1
open "/Volumes/Xcode and iOS SDK/Xcode and iOS SDK.mpkg"
You'll also need to set the clock back to a date prior to 31st March 2012 otherwise security certificates will fail validation during installation. You can safely change the date back again after installation obviously!
Frédéric Devernay has a GitHub project called xcodelegacy which works fantastic for me on Xcode 5.1.1, and needs very little work to get it going, just some downloading.
Using his project, I've managed to create universal binaries containing both ppc and i386 architectures compiled with the 10.4 SDK using GCC 4.0, all from within Xcode 5.1.1 running on Yosemite.
I've verified myself that the universal binaries created work fine on 10.5 Leopard and on Yosemite itself.
Home page here: http://devernay.free.fr/hacks/xcodelegacy
Git hub project here: https://github.com/devernay/xcodelegacy
In case someone need to restore old SDKs and PPC compiler in Xcode 4.3 and 4.5, this is a script I came up with. Note you need to set the path to the Xcode app bundle and path to Xcode 3.2.6 install at the beginning of the script.
#!/bin/bash
XCODE="/Applications/Xcode45-DP1.app"
XCODE3="/Xcode3"
# restore SDKs
cd "$XCODE/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs"
sudo ln -s "$XCODE3/SDKs/MacOSX10.4u.sdk" .
sudo ln -s "$XCODE3/SDKs/MacOSX10.5.sdk" .
sudo ln -s "$XCODE3/SDKs/MacOSX10.6.sdk" .
# restore gcc 4.0
cd "$XCODE/Contents/Developer/usr/bin"
sudo ln -s "$XCODE3/usr/bin/"*4.0* .
sudo ln -s "powerpc-apple-darwin10-g++-4.0.1" "powerpc-apple-darwin11-g++-4.0.1"
sudo ln -s "powerpc-apple-darwin10-gcc-4.0.1" "powerpc-apple-darwin11-gcc-4.0.1"
# restore Xcode option
cd "$XCODE/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins"
sudo ln -s "$XCODE3/Library/Xcode/Plug-ins/GCC 4.0.xcplugin" .
You don't need to symlink 10.6 SDK if you are using Xcode 4.3 since it comes with one.
Also the script does not restore gcc 4.2 since there are a lot of filename conflicts doing that. My goal is to restore PPC compiler and 4.0 is good enough for me.
It would be useful to have a package to just install these files into an XCode 4 implementation. (or a tarball).
FYI: 3.2.6 of Xcode3 does not include an as with ppc architecture. But I had a backup of Leopard on my computer. So I copied that one, seems to work. (Use /usr/libexec/gcc/darwin/ppc/as ).
Considering that both gcc and as are open source the only stuff that may not be redistributable is the xcode plugin and the 10.4 SDK right?
Related
In a build script, I use /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk to find the most recent MacOSX SDK. MacOSX.sdk seems to contain the most recent version of the MacOSX.sdk while the MacOSX#.#.sdk is a symlink to MacOSX.sdk (I know it seems backwards).
Example ls -al
Oct 21 10:43 MacOSX.sdk
Nov 9 14:57 MacOSX11.0.sdk -> MacOSX.sdk
My question is, is this feature documented anywhere? I would like to have a guarantee that this will work going forward, and I would like to know how far back the feature existed.
Is Xcode's SDKs/MacOSX.sdk Symlink a Documented Feature
It's technically a MacOSX<version>.sdk symlink which points to the new (undocumented) standard of simply MacOSX.sdk.
It appears the symlink itself is a relatively new, backwards compatible feature for the old convention. This convention appears to be defacto-only and therefor NOT a documented feature. Historically -- in some instances -- the symlink was even bugged and left out by the installer.
#QuinceyMorris from developer.apple.com forums summarizes this well:
"In the past, Xcode shipped with multiple SDK versions, and you could use any of the SDKs that came with the version of Xcode you were using. Currently, Xcode ships with only the latest SDK.
You no longer need multiple SDKs to target different versions of macOS. Instead, you write availability tests in your source code to choose different code paths based on the macOS version where your app is running."
For example:
Unpacking Xcode 2.3's MacOSX10.3.9.pkg, there is no MacOSX.sdk, but rather MacOSX10.3.9.sdk.
Unpacking Xcode 4.0.2's MacOSX10.6.sdk, there is no MacOSX.sdk, but rather MacOSX10.6.sdk
Most build systems will leverage a tool like xcrun to locate this e.g:
xcrun --show-sdk-path
Which on newer OSs will generally list the unversioned path e.g:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
... or if multiples are installed, you can specify the target SDK:
xcrun --sdk macosx10.14 <command>
Note, since XCode install destination can vary (as well as be named XCode Beta.app, using a helper tool to locate this directory is strongly advised.
However, using the newer MACOSX_DEPLOYMENT_TARGET technique seems to be the new "standard", and will completely avoid the versioned SDK folder, assuming it works for your needs.
I have spent an evening until some ridiculous time in the morning trying to figure out how to get Haskell's GHC to work correctly and to have Cabal install the gloss library.
After reading through every bit of documentation/error reports imaginable, even with old installs of ghc, gcc binary (instead of a symlink to clang), and brewing llvm no matter what happened one fix resolved one issue, only to then present another.
So I have a simple solution that worked for me for Yosemite and I will post it below (I wish someone else had posted it here)
Ok here is the easy solution to the headache:
Go here http://ghcformacosx.github.io/ and download the app and put it in the app directory and run it.
Add the stuff to the .bash_profile (you will see what I mean when you run it)
Run brew install llvm34 (note there was an issue with using a newer version)
Then symlink to llvm so that ghc can find it (I tried editing the ghc settings file but it didn't help. Maybe after all the stuffing around, it was the wrong version of ghc that I was editing)
Brew gave me symlinks at /user/local/bin to llvm BUT NOTE they were not called plain old llc & opt as ghc was looking for.. they were called llc-3.4 & opt-3.4, hence why it couldn't find them. Again their location can be specified in the ghc settings file, but as I had some issues with that I just created some more symlinks.
I went to /usr/bin and ran:
sudo ln -s /usr/local/bin/opt-3.4 opt
sudo ln -s /usr/local/bin/llc-3.4 llc
Which created the generic opt, generic llc that symlinked to the brew installion of the associated v3.4.2 llvm files.
Hope that saves someone an evening.
XCode comes with LLDB, presumably there is a way to enable it as the debugger to use when debugging XCode projects.
Of course being a Linux user I have become a hardcore command-line fanatic and I have a well-established Vim and Tmux workflow. Also being a code portability freak, 100% of my scripts work on both OS X and Linux.
So is there some sort of way to "Pull out" the LLDB from deep within the bowels of XCode and run it from the command line? What are the benefits of compiling it ourselves, as directed from the instructions?
I am guessing that the usual reasons to build from source apply here as well: We can get the latest bleeding edge features and bugfixes by rebuilding it. It's just better. etc. How can I check which version of clang a particular LLDB instance uses? I did compile it using the XCode project (by following those directions), and version reports:
steven#new-host-3:~/Library/Developer/Xcode/DerivedData/lldb-bvjmzslapfdmdmabqocfcogrlbfc/Build/Products/Debug Wed 3 20:37 10137
% ./lldb
(lldb) version
lldb-300.99.0
The answer won't directly help me since I already know how to build the entire thing from source, but for everyone else out there with a Mac who is thinking about ditching GDB (and actually intends to do debugging out of a command line), maybe there's a shortcut (that I skipped)!
I guess there still is a significant difference between this bleeding edge svn-sourced manually compiled LLDB and the LLDB that Apple packages with XCode and XCode CLT.
The convention on Mac OS X with Xcode 4.6 is that you either install the CommandLineTools package (which installs things in /usr/bin etc) or you prefix commands with xcrun. xcrun lldb, xcrun clang, etc. Most users of Xcode do not use command line tools so this arrangement works well. I believe you can download the CommandLineTools package alone if you're only doing command line development from http://developer.apple.com/ (I think an Apple ID is required to get access -- I think a free account will be sufficient to get the CommandLineTools package) which means you can get the full command line tools with a single 128MB download.
The change to have the canonical home for everything be in /Applications/Xcode.app is a relatively new one and the goal that drove this change was to make the developer tools relocatable. It will install in /Applications/Xcode.app if you download it from the Mac App Store, but it doesn't need to be there. You can install multiple versions of the tools on a single system - for instance, people who have access to the Xcode 5 Developer Previews will see that it installs in a separate location so the Xcode 4.6 tools are still present on the system. The xcode-select command line program can be used to specify which set of Xcode.app tools should be invoked by xcrun clang etc.
As an aside, a useful shortcut for people more comfortable building from Terminal: if you are building lldb you can do xcodebuild -configuration Debug and it will build the Debug configuration for you, no Xcode UI required.
Maybe I took the scenic route here.
% /Applications/Xcode.app/Contents/Developer/usr/bin/lldb
(lldb) version
LLDB-179.6
(lldb)
This is probably useful enough to get work done with.
It's kind of unfortunate to see that the Xcode CLT and Xcode itself come with similar tools, it's a waste of disk space.
See the sister question here.
I'm learning Ada 95 in my programming class, and I would like to install the gnat compiler on my MacBook. I have no clue as to where to get a good gnat to compile my code, and how to install it.
I currently have gedit as my text editor, because that's what we're using in our lab environment. I'm new to the Mac world so any help would be greatly appreciated.
There's an excellent free Ada compiler for Mac OS X available from AdaCore.
You should be OK with the GNAT GPL edition. Follow the Download link - choose Free Software of Academic Development - at the bottom of the page, follow Build your Download Package.
Select your platform as x86_64-darwin, 2012. Click on GNAT 2012, then on gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz (this contains all you'll need for the moment).
You'll also need Xcode (free with Mac OS X). Pre-Lion, this was (I think) an optional install on the installation DVD. In Lion or ML, you need to get it from the App Store (in ML it's at Categories > Developer Tools > Xcode). In ML, you also need to install the command line tools: open Xcode, then Xcode > Preferences > Downloads > Components, select Install against the Command Line Tools.
I say to install Xcode first, because the GNAT install needs it (you can tell whether the command line tools are installed by saying which make: if the answer comes back blank, they aren't installed). Anyway, for the GNAT install,
$ cd
$ tar zxvf ~/Downloads/gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz
$ cd gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin
$ sudo ./doinstall
You don't need the installer after it's finished, so you can delete it.
The defaults install GNAT under /usr/local/gnat, and you'll need to make sure that /usr/local/gnat/bin is first on your path (at any rate, ahead of /usr/bin). I'd edit ~/.bash_profile_common to add
PATH=/usr/local/gnat/bin:$PATH
but I still have trouble knowing which of the ~/.bash* files do what!
I have OS X Yosemite 10.10.3, and I followed the following steps.
Download GNAT from this place http://libre.adacore.com/download/configurations. Choose Mac OS X as the platform.
Execute the following commands on the terminal:
Unzip or (tar the file downloaded from the previous step, for example, as follows:
tar zxvf gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin.tar.gz
Note: this assumes that you're in the same folder as the file you downloaded in step 1.
cd gnat-gpl-2012-x86_64-apple-darwin10.8.0-bin
sudo ./doinstall
Edit your .bash_profile file under /Users/{YOUR_USER_NAME}/.bash_profile to also have the following line
export PATH=$PATH:/opt/local/bin:/usr/local/gnat/bin
Save the .bash_profile file.
Open a new terminal. You should now be able to execute gnatmake.
The answers here are quite old and are no longer the best options. Command-line only development is quite a pain, especially if you're just starting with the language. The alternative, GNAT Studio IDE, is no longer supported on MacOS X, but still supported on Linux and Windows. No big loss though, since its its a bit clunky, slow and poorly integrates with MacOS.
Fortunately, there's now a VSCode plugin enabling all the major features available in GNAT Studio, such as syntax coloring, debugging and IntelliSense, along with a better overall user interface:
https://marketplace.visualstudio.com/items?itemName=AdaCore.ada
Oddly enough, it's not as well promoted as GNAT Studio. In fact, I discovered this VSCode plugin on a whim after I having difficulty setting up my development environment. The instruction for setting up the plugin is simple. It also has the most succinct and comprehensive installation instructions for the toolchain.
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.