Odd piece of Clang 2.1 behaviour

I'm experimenting with Clang as a replacement for GCC in building my employers'
products, and liking it a great deal. It's the easiest new compiler I've dealt
with in 15 years of porting this code to a wide variety of platforms.

I'm working on Mac OS X 10.7 with the Clang 2.1 from Xcode 4.1, and it's doing
something that I could believe was deliberate, but isn't helpful to me.

Object files are created with permissions of "-rw-------". llvm-gcc-4.2 creates
them in the same setup with permissions of "-rw-rw-r--".

This creates a problem for me, because we have a centralised build system,
running under a special account, and developers working against it need to
link against object files produced by the special account. They are members
of the same group, so permissions of "-rw-r-----" would work fine.

This doesn't seem to be being caused by my umask. Obviously, I can change the
permissions on the .o files once they exist, so it isn't a big problem, but
I was curious if this was deliberate, and if so, why?

Thanks in advance,

It's a bug; IIRC, it's already fixed in clang trunk.

-Eli

For what it's worth, Xcode 4.2 includes a vastly updated version of Clang (branded "Apple LLVM Compiler 3.0" instead of "2.1" by the apple marketing people). It recently came out of Beta. I recommend upgrading to it if you can.

-Chris

Eli Friedman wrote:

> It's a bug; IIRC, it's already fixed in clang trunk.

Chris Lattner wrote:

For what it's worth, Xcode 4.2 includes a vastly updated version
of Clang (branded "Apple LLVM Compiler 3.0" instead of "2.1" by
the apple marketing people). It recently came out of Beta. I
recommend upgrading to it if you can.

That's a bit interesting. The libraries I produce are a product in their own
right, used in many different applications. It is going to be important that
the Clang-built versions be usable for development on Mac OS X 10.6 as well
as 10.7, and with GCC as well as Clang on 10.7.

If you trust Clang, this is no problem for the libraries I build from C,
and for the ones built from C++, it only requires using -stdlib=libstdc++.

But I have customers who aren't switching to Clang immediately, because
their code (which requires "permissive" with GCC) won't compile with Clang,
until they do some extra work, and they are nervous about Clang. So staying
on a Clang that definitely has a corresponding conventional GCC is going
to be good for their peace of mind.

And as best I know, Xcode 4.2 removes the conventional GCC, and only provides
an LLVM-based GCC. Is that correct?

Eli Friedman wrote:

It's a bug; IIRC, it's already fixed in clang trunk.

Chris Lattner wrote:

For what it's worth, Xcode 4.2 includes a vastly updated version
of Clang (branded "Apple LLVM Compiler 3.0" instead of "2.1" by
the apple marketing people). It recently came out of Beta. I
recommend upgrading to it if you can.

That's a bit interesting. The libraries I produce are a product in their own
right, used in many different applications. It is going to be important that
the Clang-built versions be usable for development on Mac OS X 10.6 as well
as 10.7, and with GCC as well as Clang on 10.7.

The problem is that I don't think Apple support new features in GCC.
For what I know, ARC is a clang only feature for example (but it shouldn't be an issue if you're using only C and C++).
An other example is thread local storage (__thread keyword), which is available using clang on 10.7, but not using GCC.

If you trust Clang, this is no problem for the libraries I build from C,
and for the ones built from C++, it only requires using -stdlib=libstdc++.

Shouldn't be required, as this is the default.

But I have customers who aren't switching to Clang immediately, because
their code (which requires "permissive" with GCC) won't compile with Clang,
until they do some extra work, and they are nervous about Clang. So staying
on a Clang that definitely has a corresponding conventional GCC is going
to be good for their peace of mind.

And as best I know, Xcode 4.2 removes the conventional GCC, and only provides
an LLVM-based GCC. Is that correct?

Yep. using the latest Xcode 4.2 version, I get:

/Developer/usr/bin/gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- Jean-Daniel

Jean-Daniel Dupas wrote:

The problem is that I don't think Apple support new features in GCC.

This is entirely survivable. The software has to be portable across a
lot of platforms.

Shouldn't be required, as this [-stdlib=libstdc++] is the default.

Making it explicit simply ensures it gets into documentation, and that
we don't get surprised when the default changes.

/Developer/usr/bin/gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.1.00)

llvm-gcc is the default gcc at Xcode 4.1, but that also has a non-LLVM
gcc at /Developer/usr/bin/gcc-4.2. The information I have is that isn't
present at Xcode 4.2.

thanks very much,

OK. No, there is no gcc-4.2 binary in Xcode 4.2.

-- Jean-Daniel

OK. No, there is no gcc-4.2 binary in Xcode 4.2.

Thanks for the confirmation. That's going to make life simpler if I
can stay on Xcode 4.1.

thanks,

Eli Friedman wrote:

It's a bug; IIRC, it's already fixed in clang trunk.

Chris Lattner wrote:

For what it's worth, Xcode 4.2 includes a vastly updated version
of Clang (branded "Apple LLVM Compiler 3.0" instead of "2.1" by
the apple marketing people). It recently came out of Beta. I
recommend upgrading to it if you can.

But I have customers who aren't switching to Clang immediately, because
their code (which requires "permissive" with GCC) won't compile with Clang,
until they do some extra work, and they are nervous about Clang.

FWIW, llvm-gcc provides the same source compatibility as gcc (including -fpermissive), since it's the same front end.

So staying
on a Clang that definitely has a corresponding conventional GCC is going
to be good for their peace of mind.

… and it's worth noting that GCC/LLVM-GCC/Clang all implement the same ABI, so different parts of a program can be compiled with different compilers.

  - Doug

FWIW, llvm-gcc provides the same source compatibility as
gcc (including -fpermissive), since it's the same front end.

Indeed, but for the customers that need looking after carefully,
just getting them off Mac OS X 10.5 onto something modern is a
big win, and making that path as smooth as possible this time
round is helpful.

... and it's worth noting that GCC/LLVM-GCC/Clang all implement
the same ABI, so different parts of a program can be compiled
with different compilers.

Oh, I know. Without that, I would not be attempting to go up to
Clang myself.

thanks,

Yeah there is.
$ xcodebuild -version
Xcode 4.2
Build version 4D199
$ gcc-4.2 --version
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

It's just not installed into /Developer (because it isn't used anymore for Xcode itself).
$ /Developer/usr/bin/gcc-4.2 --version
-bash: /Developer/usr/bin/gcc-4.2: No such file or directory

Chip

Are you sure you aren't just getting the gcc that was previously installed in /usr/bin?

Are you sure you aren't just getting the gcc that was previously installed in /usr/bin?

You might be right. The date on the gcc-4.2 file is July 5, whereas the date on the llvm-gcc link is October 6.

Chip

Douglas Gregor <dgregor@apple.com> writes:

… and it's worth noting that GCC/LLVM-GCC/Clang all implement the
same ABI, so different parts of a program can be compiled with
different compilers.

Hmm, is this supposed to be true for C++ as well?

Recently I tried to do an incremental build of the llvm+clang tree
after switching to gcc as a compiler, from the system's installed
clang (which was having problems at the time, thus the switch). The
resulting incremental build started spewing out link errors at some
point... which a "make clean" and rebuild fixed.

[However "switching to gcc" involved re-running configure, so the
problems may have been due to some difference in the autoconf-set
parameters...]

Thanks,

-Miles

Yes. If you have any details about incompatibilities, I'd certainly like to hear about them.

John.

Yeah, I should have at least stuck the make output into a log file or
something before doing "make clean"... oh well.

If I see this sort of thing again, I'll do better...

Thanks,

-miles

Correct. Xcode 4.1 includes Clang, llvm-gcc-4.2 and gcc-4.2.

Xcode 4.2 does not include gcc-4.2, so it includes clang and llvm-gcc-4.2. For maximum compatibility and least disruption, “gcc” is a symlink to llvm-gcc in Xcode 4.2.

-Chris