macOS Is installing XCode supposed to install C compilers?

It's not part of the standard installation anymore. You have to install something called "command line tools" I think.

You can also get gcc for OSX from other sources, e.g. here: http://cran.r-project.org/bin/macosx/

I believe that installing Xcode does install GCC.
It's required for Xcode to work, anyways, so it's a logical guess for them to both be installed at once.

Xcode has to have at least LLVM/Clang otherwise obj-c wouldn't compile.

It has the compilers, just not the command line tools by default. You need to go into your Xcode preferences and tell it to download the command line tools. It's on the same panel that lets you install the reference docs locally.

Mac OS 10.7.3 with Xcode 4.3.2

ls -alF `whereis gcc`
lrwxr-xr-x 1 root wheel 12 Mar 27 22:36 /usr/bin/gcc@ -> llvm-gcc-4.2

But as noted gcc is not installed in any way, shape or form and is only a 'link' to llvm-gcc-4.2.

Just to make it clear: Xcode does not install gcc (the gnu C compiler).

Xcode does install Apples own C-compiler, called llvm. Llvm is not fully compatible with all programs written for gcc, so use at your own risk.

thundersteele said:

Just to make it clear: Xcode does not install gcc (the gnu C compiler).

Xcode does install Apples own C-compiler, called llvm. Llvm is not fully compatible with all programs written for gcc, so use at your own risk.

Click to expand...

Clang is fully compatible with the C standard and most of the gcc extensions which is what counts. The use at your own risk remark should be left for anyone using compiler specific extensions not in the C standard. Clang is the default compiler in both OS X and freeBSD 9.

lloyddean said:

But as noted gcc is not installed in any way, shape or form and is only a 'link' to llvm-gcc-4.2.

Click to expand...

Yes, but llvm-gcc is the gcc front end on top of a llvm code generator. There are two interesting WWDC 2010 session videos about this 312 and 313.

subsonix said:

Clang is fully compatible with the C standard and most of the gcc extensions which is what counts. The use at your own risk remark should be left for anyone using compiler specific extensions not in the C standard. Clang is the default compiler in both OS X and freeBSD 9.

Click to expand...

Yes, formally what you are saying is right, I guess.

I had the following issue with GSL (a scientific/math C++ library):
It compiled successfully with GSL, and ran through a large number of test routines that were supplied together with GSL, before eventually one test failed (i.e. the result of a calculation was not what it was supposed to be). Installed gnu-gcc and re-compiled, and the error went away.
Now, I never went back to explore this. Maybe the testing routine was written using non-standard C(++), of maybe some part of the library is non-standard C++. Still, at the end of the day, it's a risk to compile it with LLVM, and the easiest way to avoid possible errors is to use gnu-gcc to compile programs written for it.

Maybe this is a very small, isolated issue, and certainly not a problem for native OSX software. The OP had problems building wget, we'll see if LLVM does the job for that program.

thundersteele said:

Maybe the testing routine was written using non-standard C(++), of maybe some part of the library is non-standard C++. Still, at the end of the day, it's a risk to compile it with LLVM, and the easiest way to avoid possible errors is to use gnu-gcc to compile programs written for it.

Click to expand...

Before you isolate the problem and find that non standard gcc extensions are used and are the sole reason that is not supported by clang, what you say is just guessing. Considering that the complete freeBSD 9 is built with Clang I'd say it's not a risk.

Lastly llvm-gcc IS gcc with the llvm backend.

subsonix said:

Before you isolate the problem and find that non standard gcc extensions are used and are the sole reason that is not supported by clang, what you say is just guessing. Considering that the complete freeBSD 9 is built with Clang I'd say it's not a risk.
.

Click to expand...

Yes, I'm just guessing. Unfortunately I neither have the time nor the C++ skills to start tracking down this issue.
If you're interested, google "GSL LLVM" gives a few related bug reports (not by me), and interestingly, also one report of a successful build and test using LLVM on a Debian machine.

I'm not claiming that there is a problem with llvm btw.

thundersteele said:

Yes, formally what you are saying is right, I guess.

I had the following issue with GSL (a scientific/math C++ library):
It compiled successfully with GSL, and ran through a large number of test routines that were supplied together with GSL, before eventually one test failed (i.e. the result of a calculation was not what it was supposed to be). Installed gnu-gcc and re-compiled, and the error went away.
Now, I never went back to explore this. Maybe the testing routine was written using non-standard C(++), of maybe some part of the library is non-standard C++. Still, at the end of the day, it's a risk to compile it with LLVM, and the easiest way to avoid possible errors is to use gnu-gcc to compile programs written for it.

Maybe this is a very small, isolated issue, and certainly not a problem for native OSX software. The OP had problems building wget, we'll see if LLVM does the job for that program.

Click to expand...

Not sure if it would have made a difference in your case, but I think its worth noting that GCC defaults to C89 (with partial C99 support & GNU extensions) & C++98 with some (most?) of 03 and Clang/LLVM defaults to C99 and C++98/Some C++03 with most of C++11 and probably most of the GNU extensions.

What I'm getting at is that it could have still been valid/standard C++ but an edge case where they were different/conflicting standards that didn't mesh right between the compilers and their default settings/standards. There are also the chance that they used a GNU extension that's not supported (or a MS extension that's not 100% compatible for that matter... see MS's 10,000 different C String copy routines...). Listening to various talks from the Clang development team at Google it seems like they are trying to make available a good level of compatibility with GCC. As such, you (or anyone else with similar issues) could try compiling using Clang and the gnu89 or similar compilation option to remedy conflicts between the two. Granted this is something that the gcc front end might do already but there is a chance that it just needs some additional tweaking or a newer version of Clang.

Also another general issue I've heard of before (in a passing conversation) was one where the programmer was dealing with porting some nasty, hacky (by today's standards), & edge case filled C++ library that only really compiled well against GCC 2.8 and died on newer versions of any compiler. I think he said that was one of the last versions of GCC to not be fully ISO C++ compliant or something along those lines.

laredotornado said:

I thought installing XCode was supposed to install those components. Is that wrong? How do I install C compilers on my Mac?

Click to expand...

Did you install it through the Mac App Store? If so, you need to install the command line tools separately from Apple's Developer site: https://developer.apple.com/downloads/index.action

thundersteele said:

Now, I never went back to explore this. Maybe the testing routine was written using non-standard C(++), of maybe some part of the library is non-standard C++. Still, at the end of the day, it's a risk to compile it with LLVM, and the easiest way to avoid possible errors is to use gnu-gcc to compile programs written for it.

Click to expand...

Want to bet that the issue is in your code?

gnasher729 said:

Want to bet that the issue is in your code?

Click to expand...

It's not in my code, since I didn't write any

And I'm not the only person that observed this:
http://lists.gnu.org/archive/html/bug-gsl/2010-04/msg00024.html