Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13953 > unrolled thread

OS X compiler

Back to article view | Back to comp.lang.c++

Contents

  OS X compiler Ebenezer <woodbrian77@gmail.com> - 2012-02-12 13:32 -0800
    Re: OS X compiler Miles Bader <miles@gnu.org> - 2012-02-13 10:26 +0900
      Re: OS X compiler Ebenezer <woodbrian77@gmail.com> - 2012-02-12 19:12 -0800
      Re: OS X compiler Juha Nieminen <nospam@thanks.invalid> - 2012-02-13 10:17 +0000
        Re: OS X compiler Miles Bader <miles@gnu.org> - 2012-02-13 20:15 +0900
          Re: OS X compiler Ebenezer <woodbrian77@gmail.com> - 2012-02-13 20:08 -0800

#13953 — OS X compiler

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

[toc] | [next] | [standalone]

#13954

Ebenezer <woodbrian77@gmail.com> writes:
> 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

-- 
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.

[toc] | [prev] | [next] | [standalone]

#13959

On Feb 12, 7:26 pm, Miles Bader <mi...@gnu.org> wrote:
> Ebenezer <woodbria...@gmail.com> writes:
> >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.

[toc] | [prev] | [next] | [standalone]

#13970

Miles Bader <miles@gnu.org> wrote:
> [*] 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).

[toc] | [prev] | [next] | [standalone]

#13971

Juha Nieminen <nospam@thanks.invalid> writes:
> 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

-- 
Politeness, n. The most acceptable hypocrisy.

[toc] | [prev] | [next] | [standalone]

#14019

On Feb 13, 5:15 am, Miles Bader <mi...@gnu.org> wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
> > 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.

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?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web