OS X compiler

[Ebenezer]

http://www.gamedev.net/topic/620135-switching-to-newer-compiler-on-osx/

With a clang build problem, I'm wondering if I should try to figure
out
the problem or try installing a newer version of gcc. Tia.

Brian
Ebenezer Enterprises
http://webEbenezer.net

 

[Miles Bader]

http://www.gamedev.net/topic/620135-switching-to-newer-compiler-on-osx/

With a clang build problem, I'm wondering if I should try to figure
out the problem or try installing a newer version of gcc. Tia.

I've no idea about the clang prob; if you want clang[*] you might try
hunting down an older version, which could have fewer OS dependencies
(it will also be missing features tho).

A bit of googling suggests gcc isn't particularly hard to compile either.
(e.g. http://www.coding.com.br/mac/building-gcc-4-6-on-macosx/ )

[*] BTW, take the clang hyperventilating on that page with a grain of
salt -- it's a neat and promising project (especially for
"non-traditional" compilation), but unfortunately it's also managed to
accumulate quite a few fanboys, who tend to ... er, overestimate its
merits.

-miles

 

[Ebenezer]

http://www.gamedev.net/topic/620135-switching-to-newer-compiler-on-osx/

With a clang build problem, I'm wondering if I should try to figure
out the problem or try installing a newer version of gcc.  Tia.

I've no idea about the clang prob; if you want clang[*] you might try
hunting down an older version, which could have fewer OS dependencies
(it will also be missing features tho).

A bit of googling suggests gcc isn't particularly hard to compile either.
(e.g.http://www.coding.com.br/mac/building-gcc-4-6-on-macosx/)

[*] BTW, take the clang hyperventilating on that page with a grain of
salt -- it's a neat and promising project (especially for
"non-traditional" compilation), but unfortunately it's also managed to
accumulate quite a few fanboys, who tend to ... er, overestimate its
merits.

Perhaps they're faking it. Thanks for the link. I'm building gcc
4.6
now and am hoping it doesn't croak after several hours.

 

[Juha Nieminen]

[*] BTW, take the clang hyperventilating on that page with a grain of
salt -- it's a neat and promising project (especially for
"non-traditional" compilation), but unfortunately it's also managed to
accumulate quite a few fanboys, who tend to ... er, overestimate its
merits.

The main reason why Apple uses clang instead of gcc (a gcc newer than 4.2
that is) is because of licensing issues. Apple is stuck with gcc 4.2 because
it's the last one to use the (L)GPL 2 license, while all the newer ones
use (L)GPL 3, which is incompatible for iPhone development. And gcc 4.2 is
getting antiquated by the month.

clang is a perfect alternative for Apple because it has a much more
liberal license that allows for iPhone development, and it has good
support for modern C/C++/Objective-C standards.

(Also, it's true: In many cases clang produces significantly better
error messages and warnings than gcc does.)

Perhaps the major (which in many cases isn't so "major") problem with
clang is that it's not as good at optimizing as gcc is. Even gcc 4.2
produces faster code than clang, not to talk about the latest gcc (which
has several significant improvements on that department).

 

[Miles Bader]

The main reason why Apple uses clang instead of gcc (a gcc newer
than 4.2 that is) is because of licensing issues. Apple is stuck
with gcc 4.2 because it's the last one to use the (L)GPL 2 license,
while all the newer ones use (L)GPL 3, which is incompatible for
iPhone development. And gcc 4.2 is getting antiquated by the month.

Yeah I know.

(Also, it's true: In many cases clang produces significantly better
error messages and warnings than gcc does.)

I know that one of clang's big "bullet points" is good error messages,
but my experience (I use [modern versions of] both compilers) the
difference isn't particularly great in practice. There are certain
very specific scenarios where clang definitely does produce nicer
messages (e.g. it tracks macro expansions better so it can reference
the offending macro when an error comes from one), but I've found them
to be relatively rare. [remember, gcc diagnostics keep getting better
too!]

Perhaps the major (which in many cases isn't so "major") problem
with clang is that it's not as good at optimizing as gcc is. Even
gcc 4.2 produces faster code than clang, not to talk about the
latest gcc (which has several significant improvements on that
department).

Clang trunk is catching up though ... I used to avoid clang for
anything but testing, because clang-generated code that ran at
literally half the speed of gcc-generated code (on some speed critical
code I care about) -- but recently the clang trunk is showing much
better results.

I think both are very usable compilers these days, if you use the
recentish versions. Gcc optimizes somewhat better, and has better
support for C++11, but clang is a bit faster in compilation (~10-15%
IME), and sometimes does offer better diagnostics. [I find it useful
to compile with both, because using multiple independent compiler
implementations helps to identify portability problems in my own code,
which might slip through the cracks in a single compiler.]

[Another issue is the standard C++ library. Clang's own library,
libc++ doesn't really seem ready for prime time (e.g. the installation
instructions basically say "don't try this if you aren't running
OSX"), and while clang can use libstdc++ (gcc's library), it's not
entirely trivial to find a version which is both recent enough to
support new C++11 features and which clang can handle... (primarily
due to the use of C++11 features in the library implementation of
C++11 classes).]

-Miles

 

[Ebenezer]

Yeah I know.

Me too. Thanks for the background info. I have to work
to tread water on OS X and Windows. Linux is sometimes
mean to me also, but I like it the most.

 (Also, it's true: In many cases clang produces significantly better
error messages and warnings than gcc does.)

I know that one of clang's big "bullet points" is good error messages,
but my experience (I use [modern versions of] both compilers) the
difference isn't particularly great in practice.  There are certain
very specific scenarios where clang definitely does produce nicer
messages (e.g. it tracks macro expansions better so it can reference
the offending macro when an error comes from one), but I've found them
to be relatively rare.  [remember, gcc diagnostics keep getting better
too!]

Perhaps the major (which in many cases isn't so "major") problem
with clang is that it's not as good at optimizing as gcc is. Even
gcc 4.2 produces faster code than clang, not to talk about the
latest gcc (which has several significant improvements on that
department).

Clang trunk is catching up though ... I used to avoid clang for
anything but testing, because clang-generated code that ran at
literally half the speed of gcc-generated code (on some speed critical
code I care about) -- but recently the clang trunk is showing much
better results.

I think both are very usable compilers these days, if you use the
recentish versions.  Gcc optimizes somewhat better, and has better
support for C++11, but clang is a bit faster in compilation (~10-15%
IME), and sometimes does offer better diagnostics.  [I find it useful
to compile with both, because using multiple independent compiler
implementations helps to identify portability problems in my own code,
which might slip through the cracks in a single compiler.]

This was a factor for me in deciding to give clang a try.
But due to that snag it will have to wait at least a bit.

So gcc built now but ...
I decided to uninstall xcode. Not sure about that but
have done the equivalent before on Linux. Now I don't
have a make program in my path and when I compile a file
by hand it fails with: "errno.h: No such file or
directory." Did I make a mistake by getting rid of
xcode? Any ideas on how to fix these problems?