Using clang/LLVM components in conventional apps?

I heard of clang+LLVM as something that potentially offered better
performance for C and C++ code than GCC on Mac OS X. Things seem to
be at too early a stage for using it for that in commercial apps
at present - I have noticed the C++ incompleteness - but I have a
few questions about how it might work in practice.

I work on a commercial product that's a library of solid-modelling
functions, which is licensed to CAD/CAM/CAE software vendors for use
in their products. On Mac OS X it's a single large dylib, plus some
C headers to compile against. It's compiled with a C compiler, not
a C++ compiler, because it's written in a special-purpose language
that compiles to C.

At one level, this should be quite straightforward: re-compile
everything with a different command.

But I haven't been able to find anything on the websites about how
you might drop a dylib built with clang into an application built
with GCC. Does this just work, via integration of LLVM into the
loader, or is it more complex than that?

I presume that if the end-user for such a library has a different
version of LLVM from me, I'm at the mercy of differences in any
behaviour? That's potentially a problem, because we have to test
this code very thoroughly.

thanks,

Dallman, John wrote:

I work on a commercial product that's a library of solid-modelling
functions, which is licensed to CAD/CAM/CAE software vendors for use
in their products. On Mac OS X it's a single large dylib, plus some
C headers to compile against. It's compiled with a C compiler, not
a C++ compiler, because it's written in a special-purpose language
that compiles to C.

At one level, this should be quite straightforward: re-compile
everything with a different command.

But I haven't been able to find anything on the websites about how
you might drop a dylib built with clang into an application built
with GCC. Does this just work, via integration of LLVM into the
loader, or is it more complex than that?
  

It's simpler, actually. The dylib doesn't contain LLVM bitcode anymore;
it's a perfectly normal machine code object. It should be (according to
the project goals) 100% binary compatible with GCC-compiled code. So
there should be no compatibility issues at all.

Sebastian

It's simpler, actually. The dylib doesn't contain LLVM bitcode

anymore;

it's a perfectly normal machine code object. It should be (according

to

the project goals) 100% binary compatible with GCC-compiled code. So
there should be no compatibility issues at all.

OK. I was under the impression the one of the points of LLVM was that
it could target the hardware at run-time: some of the examples of how
it's used for OpenGL and so on seem to work that way?

Presumably here it's just being used as a step along the route from
source to binary: would clang produce conventional .o files, or
don't you get ordinary machine code until you link?

thanks,

It's simpler, actually. The dylib doesn't contain LLVM bitcode

anymore;

it's a perfectly normal machine code object. It should be (according

to

the project goals) 100% binary compatible with GCC-compiled code. So
there should be no compatibility issues at all.

OK. I was under the impression the one of the points of LLVM was that
it could target the hardware at run-time: some of the examples of how
it's used for OpenGL and so on seem to work that way?

One can use LLVM that way, but it's not the default for Clang.

Presumably here it's just being used as a step along the route from
source to binary: would clang produce conventional .o files, or
don't you get ordinary machine code until you link?

Clang produces conventional .o files that are 100% binary-compatible with GCC.

  - Doug

Douglas Gregor [mailto:dgregor@apple.com] wrote:

Clang produces conventional .o files that are 100% binary-compatible
with GCC.

Splendid! I'll give it a try when we upgrade our build standard to Mac
OS X 10.6 and a newer Xcode than 3.0. Currently, we have stable
production
on those tools, and we can't just change without giving customers
notice.

Dallman, John wrote:

I was under the impression the one of the points of LLVM was that
it could target the hardware at run-time: some of the examples of how
it's used for OpenGL and so on seem to work that way?
  

It can be used for that. Specifically, there are applications that embed
LLVM components in order to provide such services. However, I'm not
aware of any LLVM tool that generates native executables which contain
an LLVM code generator plus bitcode.

Presumably here it's just being used as a step along the route from
source to binary: would clang produce conventional .o files, or
don't you get ordinary machine code until you link?
  

That depends on whether you enable link-time code generation.

Sebastian

On a similar note, I was recently wondering...

How would one make clang appear as one of the compilers in the
drop-down GUI in Xcode?

Is there some information on this somewhere?

-Alexei

On a similar note, I was recently wondering...

How would one make clang appear as one of the compilers in the
drop-down GUI in Xcode?

Is there some information on this somewhere?

Which version of Xcode? Since clang is a drop in replacement for GCC, one hack is to change the /Developer/usr/bin/gcc symlink to point to clang.

-Chris

On a similar note, I was recently wondering...

How would one make clang appear as one of the compilers in the
drop-down GUI in Xcode?

Is there some information on this somewhere?

Oh, another less horrible hack is to add a custom build setting to the build setting inspector of CC = /path/to/clang.

-Chris

Hmm - clang seems to be having trouble compiling Mac OS X headers:

In file included from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:24,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:24,
                 from
/Users/shadowknight/Projects/myth2/merged-1.6/Myth2Code/cseries/final_carbon.h:15:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
stdarg.h: No such file or directory
In file included from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:24,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:24,
                 from
/Users/shadowknight/Projects/myth2/merged-1.6/Myth2Code/cseries/final_carbon.h:15:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/float.h:8:24: error:
float.h: No such file or directory
In file included from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:24,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:24,
                 from
/Users/shadowknight/Projects/myth2/merged-1.6/Myth2Code/cseries/final_carbon.h:15:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29:23:
error: xmmintrin.h: No such file or directory
In file included from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:24,
                 from
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:24,
                 from
/Users/shadowknight/Projects/myth2/merged-1.6/Myth2Code/cseries/final_carbon.h:15:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:254:
error: '__m128' does not name a type
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:255:
error: '__m128i' does not name a type
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:256:
error: '__m128d' does not name a type

Are these known issues? Is it possible to pass some flags or something
to clang to work-around these?

-Alexei

This looks like clang isn't finding its versions of standard headers. How did you build/install clang?

-Chris

I've build LLVM + clang from SVN using make. Am I required to "make
install" for it to find the right headers? (I just set CC to the bin
directory where clang is created by make.)

I don't know if it's required, but I'd definitely try it :slight_smile:

-Chris

Interesting. After 'make install', it still gives the same errors, but
proceeds with the build just fine.

Of note, the errors happen during PCH generation. I guess the way
Xcode expects gcc to do PCH is different than what clang supports or
some such...

-Alexei

Looks like I spoke too soon. As soon as it gets to file actually using
stuff out of OS X headers, it dies horribly due to not finding PCH'd
headers.

-Alexei

Interestingly, when I changed the target settings to NOT use
precompiled/prefix headers, then all the C files compiled OK with
clang, but the C++ files (which as I understand are passed to gcc)
started failing with the same errors that clang was failing with when
trying to generate PCH - ie same headers not found. Those same
problems did not affect the C files.

-Alexei

Although I don't use Xcode for our project (just make), I've been able to take a production system written in C and compile and test it just fine both on OS X 10.5.x, and Linux (CentOS 5.2). So far, although I'm not running this branch in production, I've seen no issues. In addition I've been able to add block support to this branch of the code by including a link to compiler-rt (back end support for blocks) which is available on the LLVM site. For 10.5.x this compile of compiler-rt worked with just an added make. For Linux I had make small modifications, mainly ifdefing out OS X headers and including LInux built atomic builtins. With the caveat that my block testing was minimal--just have tested closure, it works as advertised. This is a distributed/clustered system which is heavily threaded, interfaces to Oracle, 3rd party voice generation libraries, and pbx systems, (placing phone calls, sending sms, im, and email), and dropping clang in place of gcc (without block support), just worked. As mentioned adding block support for 10.5.x also just worked. So I guess my point is that you should be able to start testing with it now.

Garrison Venn

... So I guess my point is that you should be able to start
testing with it now.

While this would be interesting, there is Too Much Else To Do.

best,