
Xcode, GCC, and Homebrew - craigkerstiens
http://kennethreitz.com/xcode-gcc-and-homebrew.html
======
pavlov
Unfortunately Apple's new Command Line Tools for Xcode doesn't include regular
gcc, but Apple's gcc-compatible wrapper around LLVM (i.e. /usr/bin/gcc is a
symlink that points to llvm-gcc).

llvm-gcc doesn't compile many projects correctly, including gcc itself (as of
Xcode 4.2 there were reports that it's not possible to compile a gcc cross-
compiler using llvm-gcc). Hopefully there have been improvements in this
regard.

Still, anyone who needs the real gcc will have to install it through some
other means.

~~~
simmons
I ran into this problem, myself, after I upgraded Xcode a while back. Fink was
no longer able to build a tool I wanted to install.

I wonder if there's a compelling reason for these add-on distros (Fink,
Homebrew, Macports) to be strictly "build from source" with no option for
binary package downloads. For me, it just seems to add long delays in getting
a tool installed, and adds frustrating dependencies on my Xcode version.

~~~
286c8cb04bda
_> I wonder if there's a compelling reason for these add-on distros (Fink,
Homebrew, Macports) to be strictly "build from source" with no option for
binary package downloads._

For that to happen, someone has to take responsibility for creating, managing,
and distributing those binary packages. That's much easier said than done.

So, the simple answer is that no one has, as of yet, volunteered to do the
work.

~~~
koenigdavidmj
fink installs binary packages.

~~~
simmons
My Fink seems to always want to perform builds, but I haven't really studied
it closely. I have a vague recollection of it offering binary packages for
Leopard but not for Snow Leopard when I installed it, back in mid-2010. If
Fink can provide binary packages for SL now, I definitely need to look into
it.

~~~
astrange
Nobody has been able to volunteer the CPU time to build binary packages, so
there haven't been any to download.

Fink ships apt-get which is still perfectly capable of using them.

------
singingwolfboy
When people listen to each other, wonderful things happen. Thank you for
listening, Apple.

~~~
BonsaiDen
Indeed, this also gives me some confidence that there are still a few people
around at Apple who don't like walls around their gardens :)

~~~
guns
Definitely. For instance, X is still supported on OS X after all these years,
in large part due to Jeremy Huddleston:

[http://lists.apple.com/archives/x11-users/2011/Nov/msg00058....](http://lists.apple.com/archives/x11-users/2011/Nov/msg00058.html)

It's reassuring that I will be able to continue to use my Mac and rxvt-unicode
into the forseeable future.

------
mapgrep
While this is a nice convenience for registered Apple developers, I noticed
that this download requires me to sign a confidentiality agreement and an NDA
as part of the registration process (since I am NOT a registered Apple
developer).

The nice thing about just installing the OS X developer tools off the OS X DVD
is that you do not need to enter into these sorts of legal agreements with
Apple (beyond a standard software EULA).

~~~
kenneth_reitz
It's a preview. The final version won't.

~~~
mapgrep
Thanks, but, what do you mean? Won't what? Won't require an Apple developer
account?

~~~
saurik
Won't require a confidentiality agreement and NDA.

------
mhurron
"We will recommend you don't use Xcode from the App Store but instead the
command-line-tools package"

Ok why? If you install all of Xcode, you're going to have everything included
in this tools package as well, aren't you?

~~~
doe88
No it doesn't. Xcode 4.3 is now a standalone .app package including only what
is relevant to Xcode. These command line tools are a separate install even if
you installed Xcode.

~~~
calloc
Actually it does. The binaries are all included in the .app, the secondary
installer just places binaries in the various locations around the HD.

Look at man xcrun and man xcode-select. Both of which can be used to switch to
different Xcode versions easily. In the future it looks like they are planning
on making it easier to switch between different versions of Xcode.

And using xcrun one could set up a build environment for make/config with
CXX/CC/and all other environment variables pointing to the right location in
your /Applications/Xcode.app/ folder.

One thing I don't understand is why Apple didn't just symlink the various
binaries into the Xcode app if the Xcode app is installed, instead of having
to download another 170MB file.

~~~
msbarnett
> One thing I don't understand is why Apple didn't just symlink the various
> binaries into the Xcode app if the Xcode app is installed, instead of having
> to download another 170MB file.

Probably consistency. If Xcode symlinked its binaries, then either the CLI
Tools team and the Xcode team have to sync all of their releases up, or what
version of the tools you have will depend on whether you installed Xcode or
the CLI Tools (or, if you installed both, the _order_ in which you installed
them), and projects like Homebrew would have to account for both scenarios.

Far easier to have everyone using the CLI tools using the version the CLI team
is putting out, and letting the Xcode team just worry about shipping the
versions they need for Xcode, and not supporting other usage scenarios.

edit: even if the CLI Tools never ship a release except at the same time as an
Xcode release, it's still one fewer scenario to QA.

------
weavejester
Does anyone happen to know if this covers OSX developer header files like
Appkit/Appkit.h? Emacs via Homebrew requires them to build, and they weren't
included in the GCC for OSX package.

~~~
jcurbo
It's in the article. He says it includes OS X header files that he couldn't
include in the other package.

~~~
weavejester
Oh, I managed to miss that part. Thanks for pointing that bit out!

------
jkbr
> Before installing, note that from within Terminal you can use the XCRUN tool
> to launch compilers and other tools embedded within the Xcode application.
> Use the XCODE-SELECT tool to define which version of Xcode is active. Type
> "man xcrun" from within Terminal to find out more.

> Downloading this package will install _copies_ of the core command line
> tools and system headers into system folders, including the LLVM compiler,
> linker, and build tools.

------
derrida
"All you need is a free Apple ID" - seriously Apple, what is with tracking me
every time I try to use my computer for something non-trivial?

------
miles_matthias
"Open source is incredible."

Yup, I agree. Also, with the news of Mountain Lion today, I've been worried
about how much Apple will continue making OS X a platform that any developer
can innovate on. This story has re-affirmed that further for me. Awesome!

------
malkia
I've found a problem with CMAKE and gcc from the latest Xcode command-line
tools. CMAKE simply can't discover the ABI. I've tried gcc, gcc-apple-4.2,
llvm-gcc, but finally it was "clang" that worked.

So for anyone using CMAKE, and having problems, this might save you (I was
able to recompile GLFW and CEGUI this way):

CMAKE_C_COMPILER=clang

CMAKE_CXX_COMPILER=clang++

------
andrewstewart
One problem I'm finding is that Ruby refuses to compile on this setup, giving
the following prompt instead:

<http://cl.ly/EIbT>

I'm assuming this is because of Apple's GCC build just being wrappers around
LLVM.

~~~
jfirebaugh
As of 1.9.3-p125, clang is officially supported by MRI.

If ruby-build refuses to compile with clang, you should open an issue. I've
done so for rvm: <https://github.com/wayneeseguin/rvm/issues/763>

------
kzrdude
That huge multi-gig download and install of Xcode is one reason I had for
leaving OS X for linux. The hurdle for getting FOSS software was too big.

~~~
pavel_lishin
How big was your distro's installer download?

~~~
jrockway
40MB.

~~~
batista
Yes, and then the installer downloads another 1-4 GB.

~~~
catch23
to be fair, a basic headless environment (aka server install) is still fairly
small (~300mb) even when it includes all the standard libraries, headers, and
compilers.

however, I doubt people would balk at 5gb on a laptop install as most people
don't really have space limitations there.

------
nohat
I remember a terrible experience trying to get gfortran working on osx. I
ended up permanently borking my glibc. If this doesn't use the real gcc I
imagine similar experiences may await. Nonetheless that is much better than
downloading xcode just for GCC.

~~~
ruediger
Apple doesn't use glibc.

~~~
nohat
I needed it for my gcc and gfortran install. I am not sure whether osx uses
glibc for xcode. Somehow despite removing and replacing everything related to
glibc, it was still broken. Never did figure it out.

~~~
calloc
glibc is not used by the base system. So if you installed glibc yourself then
the problem is not Apple's.

~~~
nohat
Sure, the problem was installing gfortran, which (as I recall) requires the
real gcc. I suspect (though I never did figure out what exactly was wrong)
that some sort of a library conflict with xcode's gcc was responsible. As this
package is still not the real gcc (they don't want gpl v3 I believe) anyone
who wants eg. gfortran will still need a separate installation.

~~~
nknight
gcc and glibc are different things, and gcc does not require glibc. I don't
know that glibc even runs on OS X/Darwin, it would seem strange for any time
to be invested in such an endeavour.

~~~
nohat
gfortran requires glibc.

~~~
nknight
I can't find any evidence of that. The gfortran 4.3 release notes strongly
imply it doesn't:

" _Support for backtraces on glibc-based systems via the -fbacktrace option is
now implemented. On all systems, a coredump can be generated for errors in the
run-time library using `-fdump-core`._ "

The GCC suite has a pretty clear history of not being dependent on glibc, and
some searching brings up no mention of it requiring glibc, and a few mentions
of people clearly building it without glibc.

~~~
nohat
[http://old.nabble.com/GLIBC-and-executable-builds-on-
Gfortra...](http://old.nabble.com/GLIBC-and-executable-builds-on-Gfortran-
Wiki-td27320153.html)

'I have been attempting unsuccessfully to try the latest gfortran snapshot
executables...The reason for the problem is that they require the bleeding-
edge version of GLIBC to run:'

[http://www-zeuthen.desy.de/linear_collider/cernlib/cernlib_2...](http://www-
zeuthen.desy.de/linear_collider/cernlib/cernlib_2005.html)

key excerpt being: 'One problem is that the functions csqrt, csqrtf, csqrtl of
libm (glibc) which are used by gcc4 are still buggy for x86_64
architectures...'

~~~
nknight
Your first link is about gfortran executables for _Linux_ (specifically a
specific snapshot build, not the source code itself), not OS X. Your second
one is about glibc systems, not OS X, is over six years old, and complains
simply about buggy functions in glibc -- what is it that makes you think using
glibc would solve a glibc problem?

Neither of these in any way imply a general dependency on glibc. On the
contrary, the second one implies you'd have more luck without it, if the issue
were still extant -- which it's not, the bugs were closed out six years ago.

~~~
nohat
First: Yep, there's not much available about compiling gfortran for osx. The
link does show an example of gfortran requiring glibc - which is the point you
were disagreeing with.

Second: just another example (by descending order of googleableness) of the
main gcc requiring glibc.

Quite possibly there is an osx (or other bsd) specific c library that can
substitute for glibc, but I did not find it, and gfortran will complain
without it.

'what is it that makes you think using glibc would solve a glibc problem?' Eh?
I used glibc to solve a 'missing glibc' problem. I then had other problems
with glibc which I attempted to solve.

~~~
nknight
You're not understanding. The first example "requires glibc" because the
binaries were linked against glibc, just like they'd be linked against OS X's
libc if they'd been built for OS X.

The second example is, again, an issue of gcc being built against glibc. You
can build it against any libc you want, but when built against glibc, the
resulting binaries are obviously going to use glibc.

You appear to have a fundamental misunderstanding of the difference between
the requirements of source code, and the requirements of the binaries built
from them. The latter are not the same as the former, and will vary depending
on how you built the source code.

And when I just built gfortran, it didn't complain about the lack of glibc at
all. If yours was complaining, I think you must have configured something
incorrectly, though it escapes me what that could be.

------
boulderdash
can this live side by side the existing xcode system?

------
soc88
> You can now setup a complete OS X develop environment with a single 171.7 MB
> package download.

And then, I LOLed.

~~~
kenneth_reitz
It was 4GB.

