Xcode, GCC, and Homebrew | Hacker News Reader

Xcode, GCC, and Homebrew

kennethreitz.com

646 pointscraigkerstiens103 comments

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.

Why is it not possible to compile gcc with llvm-gcc? The last time I checked llvm-gcc compiles C and C++ with most GNU extensions.

Because of bugs and age, the gcc-gcc that Apple shipped when it shipped gcc-gcc couldn't compile the latest gcc either.

(And llvm-gcc is based on that version, which is 4.2.1 or something, about 5 years old)

The gcc installed by Xcode 4.0.2 is able to compile working gcc cross-compilers. The llvm-gcc installed by Xcode 4.1+ isn't.

This is problematic for the Cocotron project [1], which is an Xcode-compatible cross-compiler environment for creating Windows/Linux ports of Cocoa apps. Currently one has to revert to Xcode 4.0.2 to build Cocotron's cross-compiler, then upgrade back to 4.2... This is not terribly convenient. (I guess the long-term solution is that Cocotron either has to add a dependency on a non-Apple gcc, or needs to switch to clang for its cross-compiler.)

[1] http://code.google.com/p/cocotron/

Yes, but the current Xcode doesn't include non-llvm gcc, so it isn't really a surprise that the Command Line Tools for Xcode doesn't include it either.

Does clang compile these projects correctly? If not, have you filed a bug? (http://llvm.org/docs/HowToSubmitABug.html)

Most of the times you should be submitting bugs to the program that won't compile instead of clang. A lot of software that doesn't compile with clang depends on gcc extensions (most of which are now "official", but have different syntax) or broken behavior in gcc.

You really shouldn't be using terms like "regular gcc" or "real gcc", they don't mean what you seem to think they do. GCC is a modular system specifically to provide for things like LLVM-GCC. LLVM-GCC takes the same form as other GCC back-ends for other platforms. i386 has a GCC backend, ARM has a GCC backend, IA64, MIPS, SPARC... Which of these do you nominate to be "real gcc"?

The only measure by which llvm-gcc is not "real" is that it's not included in the core gcc distribution.

Point taken. But when llvm-gcc doesn't compile the code that every other instance of gcc found on modern platforms does, it's hard to argue that it's the same thing.

Edit -- the llvm-gcc project doesn't seem to share your opinion of the project as being "just another back-end". They certainly don't claim that it's fully compatible, only that it supports "many" features, "most" options, "a number of" extensions:

"Being derived from the GNU Compiler Collection, llvm-gcc has many of gcc's features and accepts most of gcc's options. It handles a number of gcc's extensions to the C programming language."

http://llvm.org/cmds/llvmgcc.html

It's just a tradeoff. LVM offers certain benefits, at the expense of being completely full featured.

This is SOP for GCC backends. Not all platforms support all GCC features. And if you really think there aren't problems building the same code across the various official GCC backends, you're not paying attention. Ask the Linux kernel guys about GCC's code generation oddities.

"And if you really think there aren't problems building the same code across the various official GCC backends, you're not paying attention. Ask the Linux kernel guys about GCC's code generation oddities."

You don't even have to go as far as kernel developers. From a 'write once, compile everywhere' perspective, GCC is actually pretty bad. I used to work at a company that built and deployed to somewhere in the neighborhood of 20 different *nix platforms, over 6 different hardware architectures, running various GCC versions. Working around version- or backend-specific GCC issues was almost a daily task, and it wasn't getting any better with later versions.

It's not that GCC is 'bad', but it's not holy either, not by any stretch of imagination. There's a reason Apple decided to push clang as an alternative. I believe clang+LLVM will some day replace GCC on Linux and other platforms that use GCC as well.

No no, LLVM-GCC really isn't "real gcc".

All the backends which gcc publish share huge amounts of code, in particular all the optimizations framework in the shape of the SSA representation and GIMPLE, support for generating debugging information via DRAWF.

LLVM-GCC just takes the minimum amount of GCC and replaces the entire back-end.

I'll install Apple's LLVM frontend when I can use it to generate ppc object code.

LLVM has had a PowerPC backend for years http://llvm.org/docs/CodeGenerator.html#targetfeatures .

Do you mean something more specific?

Yes, I'm aware. It's Apple's LLVM that lacks PowerPC code generation:

http://stackoverflow.com/questions/7137480/how-do-i-add-ppc-...

http://www.cocoabuilder.com/archive/xcode/299924-no-ppc-from...

New tools lose support for obsolete platforms, film at 11?

It's been 6 years. The world has moved on, and Apple no longer has any commercial interest in PowerPC. You really expect them to keep bothering with it?

I'm not really concerned with Apple's financial interests. I'm concerned with their software tools and their demonstrated willingness to support the hardware they sell.

Show me a mass-market PC manufacturer that continues supporting 6 year old consumer hardware.

Nope, don't try to shift the issue. We're talking about simply allowing others to compile code for PPC — not releasing brand new operating systems. Apple isn't merely ignoring it — they're going out of their way to prevent even third-parties from supporting it.

I don't understand this belief that Apple should support obsolete technology.

Lion is the _second_ version of OS X not to even run on PPC. Why should the developer tools they distribute for Lion support it at all?

They're not "going out of their way to prevent third parties from supporting it" any more than everybody else who doesn't ship an operating system with a PPC compiler. That includes Windows, most Linux distros, your grandma, the corner grocer, President Obama…

Apple isn't actually stopping you from compiling for PPC. They just aren't shipping the compiler themselves. AFAIK, they don't ship any compilers for hardware they don't support — no VAX, no MIPS, no M68k — PPC is not special in that respect. I don't see what's so terrible about that.

I just downloaded Xcode Tools 1.0 from Apple's developer site, for free (I'm not a paid developer). Xcode 1.0 was released in 2003 for OS X 10.3.

Also available are 1.5, 2.3, 2.4, 2.4.1, 3.0, 3.1, 3.1.1, on through to the latest 4.x versions, free for the taking. All versions prior to 4 will happily build code for PowerPC.

What is it you think they're preventing anyone from doing again?

That's great. Now install one of those on Lion. And you can't run anything earlier than Lion on any Mac sold today.

If you are compiling for PPC architectures, why are Snow Leopard/Lion of any concern? This is just a pointless whine about nothing in particular. If we all shared your attitude to the advancement of technology, we'd all still be using punch cards. The PowerPC platform is dead. They announced it's death at least 7 years ago. Move on.

I doubt that a five year old GCC would much better choice for average developer/homebrew-user.

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.

> 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.

fink installs binary packages.

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.

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.

Homebrew does have binary packages (we call them bottles). I'm the guy who implemented the feature and I am realising that as I didn't shout very loudly people don't realise that it exists.

For example Qt has a bottle: https://github.com/mxcl/homebrew/blob/master/Library/Formula...

The reason we aren't doing this for more packages is basically people power and hosting (as I'm not sure Sourceforge would be happy we hosting the number of binaries we'd want to have).

Hope that explains a bit. Feel free to comment if you think we're taking a good/bad approach here.

I think I do have a better picture of the situation now, thanks. (And thanks to the others above who elaborated on the state of binary packaging in Macports and Fink.) I can certainly understand finite time and resources, and I'm grateful to those of you who assemble these packages.

Since 2.0, Macports can install binaries if available.

http://lists.macosforge.org/pipermail/macports-users/2011-Ju...

In my experience, those are quite common now - most of the packages I install are delivered as binaries.

Presuming one can get it to compile; is there any reason we can't have gcc in Homebrew now? Since it's not included anymore, it doesn't clobber any default software[1] (anything that expects `gcc` to be ordinary gcc stands a chance of breaking anyway)

[1] https://github.com/mxcl/homebrew/wiki/Acceptable-Formula

I use FSF/GNU/GCC-gcc as my primary gcc, unfortunatly it breaks almost every project that have OS X build scripts since it doesn't accept a lot of Apple-specific options (-arch, I am looking at you).

`brew install https://raw.github.com/adamv/homebrew-alt/master/duplicates/... should work.

> llvm-gcc doesn't compile many projects correctly, including gcc itself

While strictly true, it's kind of irrelevant. The official stance is that GCC is the only compiler that is supported to build recent versions of GCC. This has been true since some point around GCC 4.0.

Here's what I recommend for installing "real" gcc: http://caiustheory.com/install-gcc-421-apple-build-56663-wit...

GCC has been on the way out for a long time since they switched to GPLv3. The latest GCC version provided by Apple was 4.2 which is really quite outdated now.

Clang is a faster and BSD-licensed compiler that Apple is putting all its weight behind now. LLVM-GCC has also been deprecated as it was removed as-of LLVM 3.0.

Clang is the future and it's the default compiler with the Command Line Tools. We just need to wait for upstreams to fix the various issues.

It's worth noting that this is why monocultures are bad. For all the love of GCC (and it is great) we now have a huge quantity of open-source software that only compiles with one compiler. This is a shame and hopefully Clang will help rectify that.

That also means a huge amount of open source software that makes OS X more useful (esp. as a developer OS) is going to get harder and harder to compile on OS X. Which in turn is making OS X a less attractive platform.

You could make the same argument about 64-bit Linux. It got fixed. The same will happen on OSX. People (myself included) will write patches and get them accepted upstream.

Then such software should be modified so that it does not depend upon GNU extensions.

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

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 :)

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....

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

This is indeed great news. Thanks to everyone who was involved in making this happen, it's fantastic news.

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).

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

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

Won't require a confidentiality agreement and NDA.

The NDA covers prerelease software, which this is not.

Not true. In addition to keeping pre-release software confidential, you are obligated "not to disclose, publish, or disseminate any Apple Confidential Information" and "not to use Apple Confidential Information in any way."

Apple Confidential Information is defined to include, in addition to pre-release software, "pre-release hardware," "[pre-release] related documentation and materials," and "any information disclosed by Apple to you in connection with Apple Events or Paid Content (defined below)." Paid Content is "certain proprietary content (including, without limitation, video presentations and audio recordings) that Apple may make available to you from time to time for a separate fee." Apple Events are defined to include "certain Apple developer conferences, technical talks, and other events (including online or electronic broadcasts of such events)."

Also, Apple may "modify this Agreement, including any rules and policies at any time. You will be responsible for reviewing and becoming familiar with any such modification."

Relevant clauses below. I've highlighted the above quoted bit in context. Full PDF at https://developer.apple.com/programs/terms/registered_apple_...

If you're fine abiding these terms, by all means use this installer. I'm not saying this is evil or even neccesarily onerous. I Am Not A Lawyer. What I am saying is that this is a new layer of legal agreements which can be bypassed via the DVD install. So there is some degree of tradeoff.

(Update: Added modification clause quote, URL to full agreement.)

---

4. Confidentiality. You agree that any Apple pre-release software and/or hardware (including related documentation and materials) provided to you as a Registered Apple Developer ("Pre-Release Materials") and any information disclosed by Apple to you in connection with Apple Events or Paid Content (defined below) will be considered and referred to as "Apple Confidential Information". Notwithstanding the foregoing, Apple Confidential Information will not include: (i) information that is generally and legitimately available to the public through no fault or breach of yours, (ii) information that is generally made available to the public by Apple, (iii) information that is independently developed by you without the use of any Apple Confidential Information, (iv) information that was rightfully obtained from a third party who had the right to transfer or disclose it to you without limitation, or (v) any third party software and/or documentation provided to you by Apple and accompanied by licensing terms that do not impose confidentiality obligations on the use or disclosure of such software and/or documentation.

5. Nondisclosure and Nonuse of Apple Confidential Information.

[PREVIOUSLY QUOTED BIT]

--------->Unless otherwise expressly agreed or permitted in writing by Apple, you agree not to disclose, publish, or disseminate any Apple Confidential Information to anyone other than to other Registered Apple Developers who are employees and contractors working for the same entity as you and then only to the extent that Apple does not otherwise prohibit such disclosure. Except for your authorized purposes as a Registered Apple Developer or as otherwise expressly agreed or permitted by Apple in writing, you agree not to use Apple Confidential Information in any way, including, without limitation, for your own or any third party's benefit without the prior written approval of an authorized representative of Apple in each instance. You further agree to take reasonable precautions to prevent any unauthorized use, disclosure, publication, or dissemination of Apple Confidential Information. You acknowledge that unauthorized disclosure or use of Apple Confidential Information could cause irreparable harm and significant injury to Apple that may be difficult to ascertain. Accordingly, you agree that Apple will have the right to seek immediate injunctive relief to enforce your obligations under this Agreement in addition to any other rights and remedies it may have. If you are required by law, regulation or pursuant to the valid binding order of a court of competent jurisdiction to disclose Apple Confidential Information, you may make such disclosure, but only if you have notified Apple before making such disclosure and have used commercially reasonable efforts to limit the disclosure and to seek confidential, protective treatment of such information. A disclosure pursuant to the previous sentence will not relieve you of your obligations to hold such information as Apple Confidential Information.

6. Confidential Pre-Release Materials License and Restrictions. If Apple provides you with Pre-Release Materials, then subject to your compliance with the terms and conditions of this Agreement, Apple hereby grants you a nonexclusive, nontransferable, right and license to use the Pre-Release Materials only for the limited purposes set forth in this Section 6; provided however that if such Pre-Release Materials are accompanied by a separate license agreement, you agree that the license agreement accompanying such materials in addition to Sections 4 and 5 of this Agreement shall govern your use of the Pre-Release Materials. You further agree that in the event of any inconsistency between Section 4 and 5 of this Agreement and the confidentiality restrictions in the license agreement, the license agreement shall govern. You agree not to use the Pre-Release Materials for any purpose other than testing and/or development by you of a product designed to operate in combination with the same operating system for which the Pre-Release Materials are designed. This Agreement does not grant you any right or license to incorporate or make use of any Apple intellectual property (including for example and without limitation, trade secrets, patents, copyrights, trademarks and industrial designs) in any product. Except as expressly set forth herein, no other rights or licenses are granted or to be implied under any Apple intellectual property. You agree not to decompile, reverse engineer, disassemble, or otherwise reduce the Pre-Release Materials to a human-perceivable form, and you will not modify, network, rent, lease, transmit, sell, or loan the Pre-Release Materials in whole or in part.

The only thing this NDA covers, potentially, is if you have an iOS developers license. That would probably be covered under "paid content".

It does not cover xcode, no matter what where the installation comes from or the GCC bundle. That is release software, and is not defined in the context of the confidential information.

The start of the agreement says it defines "the terms that govern your participation as a registered Apple developer." This "participation" presumably includes downloads of the OP software, since this software is presently firewalled off for registered developers only.

There is no reference anywhere to being restricted to iOS or iPhone/iPad, including in the paid content section.

But if you're a lawyer (?) and certain of this point, I'd be relieved to take your advice, as I've purposely avoided registering as an Apple dev :)

Here is the agreement (PDF) https://developer.apple.com/programs/terms/registered_apple_...

(Updates: Link to agreement, quote from agreement.)

IAAL, and I think you should make up your own mind about what the agreement means. Personally, I think you're over-thinking it, but you shouldn't take my advice, because I don't represent you in this instance. It's a shame that something so simple has to be so dressed up by Apple's legal group in obfuscated language. I also fault Apple for deferring to its outside counsel on these matters. There's nothing stopping them from using plain english that everyone can understand in these agreements. Having said that, I read so many of these things, that I recognize 75% of it as pure "boilerplate" that is for all practical purposes ignored by everyone.

Apple requires developers to "register" and sign NDAs to download a command-line gcc? For real?

It seems not a week goes by without another reason to be glad I never touch that platform.

Fellow software developers, show some self respect. Quit enabling this abuse.

"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?

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.

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.

> 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.

I'm inferring that they are saying this to the people that only need GCC for homebrew. I don't use Xcode for anything and I hate the idea of installing all of it on my small SSD just for GCC. I've used his OSX-GCC package before and can't wait to use the "official" version now. Kudos!

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.

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

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

> 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.

"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?

"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!

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++

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.

Tell ruby to fix their shit and use clang instead.

Having the same issue here.

And I'm guessing, from the submitted article, re-installing 'osx-gcc-installer' wouldn't work.

Hopefully, Ruby will work with newer tools soon.

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

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.

How big was your distro's installer download?

I'd guess something between 150 MiB and 4 GiB.

Mine was 663mb... But I also changed back to Linux from OSX because the window manager sucked, and there was only poor package management then.

40MB.

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

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.

If a linux install is 5GB, then you're choosing yourself which packages to install. Not so in this case.

I decided this in 2005, when a multi-GB download and 4GB install was relatively larger. And no it's not just a one-time thing, I had multiple laptops and I did reinstall them (adding linux to try out etc).

Well now with this new small download you can come back to OS X then! :-)

How is a one-time download while setting up your system of any significance at all? Sure sounds like picking a screwdriver based on how fast you can unbox it.

IAWTC. I'm on the fence about making the move from OS X to Linux. I've spent far too much time fighting unnecessarily complicated issues like this in the Mac environment. GCC issues. Lion Segfaults. MacPorts. Homebrew. Headaches.

Almost all of the tools I need I can install in minutes in Debian with apt-get. It's reliable, easy and gets me doing work instead of crying while I open 20 tabs trying to find solutions to obscure bugs on Google.

If what you want is a Linux userland, by all means, err, use Linux.

Although, the en vogue thing to do is to use a Linux in a VM. You get to keep OS X and all it's friendliness and indispensable proprietary programs, and you get to have a full Linux dev environment that's also easy to backup and "snapshot".

(Now, if the commercial software for OS X, from iWork to Photoshop, and from XCode to pro audio/video drivers, is not "indispensable" to you, by all means, use Linux).

I'm (legitimately) curious which proprietary programs you think are indispensable? Really the only one I can name is Photoshop/Illustrator, and for those I think people use Wine.

Depending on your job LOTS of proprietary programs are indispensable.

Not necessarily just one though, they could be 2-3 proprietary options that have absolutely nothing competitive in OSS land.

(If people use Wine for some of them, its beside the point: that only re-inforces they do find them indispensable. Not to mention that very few pros use Wine for their work, and that Wine doesn't work 100% glitch free).

As for what programs I think. Well,

• Photoshop is one of them, sure. GIMP misses a lot still that professional graphic designers need and use everyday, especially in it's CMYK workflow. Same for Illustrator.

• InDesign (or Quark for some) is also indispensable. The only OSS competitor, Scribus, is not even close.

• Programs to design and edit fonts. Nothing with the breadth/ease of the few commercial options.

• Logic/Cubase/Sonar/Live/Pro Tools are also indispensable. Nothing comparable to OSS. Same for the multitude of pro quality plugins, from Waves to UAD.

• Premiere/Avid/FCP(X) etc. Video in OSS land is a royal pain, and nothing of the short and extend of those programs exist.

So, graphic design/dtp/video/music/sound (anything media/multimedia in short) is a no go. And I think not only in the high end, but also in the everyday consumer space. GIMP does't have the ease of use of Photoshop Elements. Nor is there something as powerful but simple as Premiere Elements or iMovie. Something as simple as editing your daughter's birthday video and adding one two effects and titles can be a world of pain. Tons of other things, from big to small, like CD labeling or card-making software with hundreds of templates to pick.

Lots of other things I guess, but as they are not exactly in my workflow, I don't know about them. Is there Mathematica/Matlab for example? or Autocad? What's the state of 3D modelers? etc.

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.

Apple doesn't use glibc.

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.

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

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.

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.

gfortran requires glibc.

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.

http://old.nabble.com/GLIBC-and-executable-builds-on-Gfortra...

'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...

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...'

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.

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.

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.

can this live side by side the existing xcode system?

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

And then, I LOLed.

It was 4GB.

Reply on news.ycombinator.com