Clang 3.5 Release Pre-Pre-Pre-Announcement

Are there any plans to integrate the new openmp support into the llvm/clang 3.5 build process? I have been able to build the current llvm/clang/compiler-rt/openmp svn on Mac OS X 10.9 out of tree with…

pushd projects/openmp/runtime
make compiler=clang

and then

OPENMP_DIR=ls projects/openmp/runtime/tmp | grep dyn
pushd projects/openmp/runtime/tmp/$OPENMP_DIR
install -m 755 libiomp5.dylib %i/opt/llvm-%v/lib/libgomp.dylib
install -m 644 *.h %i/opt/llvm-%v/lib/clang/%v/include

in our fink llvm packaging.
It would be nice to see the cmake build machinery updated to automatically build and install openmp if its sources are placed in the projects subdirectory of the llvm-3.5.0 source directory. Even if there isn’t cmake build integration, but assuming an openmp 3.5.0 tar ball will be released for llvm/clang 3.5.0, the flag for openmp support needs to be synced to the library name generated in openmp. Currently, the clang flag -fopenmp flag emits -lgomp whereas the openmp svn currently produces a libiomp5.dylib instead. Also, the clang compiler currently has to be passed an explicitly library path to the location of the libgomp.dylib with -L. While the openmp headers can be found by clang when placed in clang’s include directory, the libgomp.dylib shared lib isn’t found when placed in any of the llvm/clang internal lib directories. If the file is going to be renamed as libgomp.dylib, it should be buried in the llvm/clang directories so that it doesn’t collide with the FSF one. I can see the rational of using libgomp.dylib, so that configure and cmake detection of openmp is triggered, but in the long run it probably should be using a different shared library name.
ps I found on 10.9, that current llvm/clang/openmp can compile and run all of the example code at to build except for omp_workshare2.c. FYI, there appears to be an issue with building current openmp on 10.8 using the same approach. The openmp code appears to compile but the build fails with…

make[1]: Leaving directory ‘/sw/src/’

It appears that the failure in the openmp build is due to a race condition as if I use…

make -j1 compiler=clang

the failure in building openmp on my 10.8 box disappears.

I have the openmp support in llvm 3.5svn now built on 10.7 using Xcode 4.6.3 and 10.8/10.9 using 5.1.1. The 10.7 build required the hack…

perl -pi -e ‘s|list(APPEND SANITIZER_COMMON_SUPPORTED_DARWIN_OS iossim)||g’ projects/compiler-rt/CMakeLists.txt

to suppress building libclang_rt.asan_iossim_dynamic.dylib. The compiler-rt build now expects the iPhoneSimulator7.0.0.sdk but Xcode 4.6.3 only has the /iPhoneSimulator6.1.sdk. I tried tweaking that back to 6.1 but the build of llibclang_rt.asan_iossim_dynamic.dylib. wants link to a copy of /Applications/ as a x86_64 binary but it only exists as i386.


Hi Jack,

I didn’t have any specific plans for OpenMP in the release. If you’d be willing to test and build for OpenMP, then we could release it. :slight_smile:



Having OpenMP together with clang would be awesome! If there is additional need for testing, I’d be happy to volunteer for that.


Actually,the solution we are going to use in fink is to apply a diff of current clang-omp (which is based on stock clang 3.4) from commit f9e2fd7640f8fc06ebe1ef2f065c6158f6b4b6ef against stock clang 3.4 to our llvm34-3.4.1 package in fink. This is built against a openmp r208472 pull from trunk at The resulting clang 3.4.1 compiler defaults -fopenmp to -liomp5 (as that switch over as already occurred in clang-omp github). It passes all of the OpenMP3.1_Validation except for a known failure ( as well as all of taskbench-1.0-20110715 on x86_64-apple-darwin11/12/13. It should appear in the fink packaging set after we sort out some unrelated packaging issues.

FYI, the llvm34-3.4.1-0c package is now in the 10.7 tree of the fink project and provides integration of the current clang-omp git and openmp svn into the stock llvm 3.4.1 release. It would be nice if clang-omp could be merged into clang svn in time for the 3.5 release.