Note that the current GCC 4.2.1 isn't even GNU GCC anymore, it's the llvm-gcc frontend, with the same LLVM backend that clang uses (not sure how long ago this became default):

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)

If you want the "real" GCC you need to build from code even with 4.2. I haven't noticed any real issues with llvm-gcc, though.

Oops, it looks like Apple does still include GNU GCC, hidden away:

$ /usr/bin/i686-apple-darwin11-gcc-4.2.1 --version
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

This isn't even a listed option in Xcode anymore, just llvm-gcc (default) or clang (listed as "Apple LLVM compiler".) You can pick "other", but that's entered by bundle id and I don't feel like figuring out if one even exists for GNU GCC. :)

If you need advanced features like C++11 (formally known as C++0X), Apple did provide these in llvm-gcc. Though it's not enabled by default; you'll need to turn it on in the project properties.

.
> 4. It is recommended that you install the commandline tools using the separate installer available from connect.apple.com, rather than from within the Xcode program.

Where's that recommended?

> 5. … run the following command in terminal to insure that the proper path is set (change the path accordingly if you've installed it somewhere else):

> sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

The xcode-switch script appends /Contents/Developer to the pathname so it's not required there.

I saw some early reports on different forums that people installing the commandline tools from within Xcode were having issues, but those went away when they used the standalone installer.

I've witnessed a situation in which an earlier version of the xcode-select script will not automatically append /Contents/Developer, which is why I listed the full path explicitly.

Useful tips. I ran into the path issue with Homebrew myself, and discovered it was because xcode-select still thought my path was "/Developer".

I couldn't update the command line tools from within Xcode with 4.3 (had to install the package manually), but this seems to be fixed with 4.3.1; I checked /usr/bin after updating 4.3.1's command line tools and those did update properly.

Thanks for the explanation, Negritude.

I'd only been able to update pre-4.3 Command Line Tools with 4.3 on my MBP. Now it works with 4.3.1 on my other two systems after this change:

- Adds installation of command-line tools to the Downloads preference pane


Downloading newer documentation worked okay, except for iOS 5.1 Library being finicky about the dev account login (like what you mentioned in another comment, Psychos). After that I manually deleted older and unwanted docs from ~/Library/Developer/Shared/Documentation/DocSets to regain some space.

...and 4.3.2 seems to have broken in-app updating of command line tools, again. Updated Xcode, then got a "You don't have access to download Command Line Tools" message. (Other components updated fine in-app.)

Went to developer.apple.com with the same account, and Command Line Tools (Late Mar 2012) downloaded and installed fine, and now shows up as updated within Xcode.

Only issue I had updating Command Line Tools from Xcode 4.3.2 was being prompted to reenter developer account info on one system. CLT and doc updates were more troublesome with 4.3.1, including deleting/resaving dev acct info stored in the keychain a few times.

The first bullet on this page's What's New deals with that and why.

Actually now Xcode is an app, and not an installer. So from now on it will be updated via the App Store, instead of downloading an installer, and having to install that, as it has been. So next time you will see the update via the App Store.

I'm not sure how best to handle command line tools, etc. that moved from /Developer to under /Applications/Xcode.app being newer than what's installed under /usr, etc. Didn't pre-4.3 Xcode updates keep some of that stuff in sync automatically? Seems like that'll now be a manual process after most Xcode app updates, by downloading and installing the optional Command Line Tools for Xcode package. Command Line Tools is listed as Installed under Xcode > Preferences > Downloads > Components and clicking "Check and Install Now" displays "No updates available" so that only handles what's bundled with the app.

Hmm, looking at my backup, it looks like my CURRENT set of /usr/bin stuff came from my last Xcode install! So, essentially, it seems like the old tools weren't uninstalled at all. (They might have been on the system initially, though, and just updated by Xcode along the way...but still.)

So yeah, now Xcode.app has its own set of those tools now, which it doesn't populate into /usr/bin anymore it seems. Definitely annoying, and seems like a bug since that's likely to break things over time as versions drift, even if nothing breaks right away.

I guess you could always add "/Applications/Xcode.app/Contents/Developer/usr/bin" to the start of your $PATH for now...

Funny, I installed 4.3 and it did NOT move the old /Developer folder to the trash. Fail again. :(

It asks you. Perhaps you chose otherwise.

.
> So, essentially, it seems like the old tools weren't uninstalled at all.

During the first launch of 4.3, the Remove Older Xcode Tools dialog only offered to trash /Developer and /Applications/Install Xcode.app. Apparently any other older Xcode-related stuff was left untouched, including leaving orphaned app references in Launchpad's Developer folder when /Developer was trashed.

> So yeah, now Xcode.app has its own set of those tools now, which it doesn't populate into /usr/bin anymore it seems.

For some reason, Command Line Tools wasn't listed under Xcode > Preferences > Downloads > Components right after installing 4.3 on my older MBP (like it had been earlier on my MBA and mini). But after clicking "Check and Install Now" it showed up with an Install button. Surprisingly, clicking that prompted for developer account info (which I entered) and then proceeded to download and install the same stuff as in the standalone Command Line Tools for Xcode package.

So, I was able to update CLT from Preferences > Downloads on the MBP but not on the MBA and mini. The 4.3 migration process can be quirky.

> I guess you could always add "/Applications/Xcode.app/Contents/Developer/usr/bin" to the start of your $PATH for now...

That wouldn't handle scripts, etc. with dependencies on files in /usr/bin, etc.

Components of the development environment, possibly with varying versions, that exist under Xcode, traditional UNIX, and other locations can be a source of confusion and unintended results.