llvm-3.7: Update to release and add +openmp

[eborisch (Eric A. Borisch)]

(Note) This discussion started on mailing list while trac was offline. ​https://lists.macosforge.org/pipermail/macports-dev/2015-September/031349.html

Attached are a Portfile patch and patchfile to add OpenMP support to clang-3.7 as well as update llvm/clang to the 3.7.0 release.

The openmp-locations.patch adds -L<prefix>/lib/libomp and -I<prefix>/include/libomp to the appropriate compilation commands in tools/clang/lib/Driver/Tools.cpp such that, when combined with configure option (--with-clang-default-openmp-runtime=libomp), 'clang[++] -fopenmp' will 'just work'.

I've updated (r139987) libomp to install into <prefix>(include|lib)/libomp/ such that the impact to compilation is minimized (by not using -I<prefix>/include and -L<prefix>/lib directly).

Please review and comment.

[eborisch (Eric A. Borisch)]

The patch also enforces a variants match on +assertions between clang and llvm; in my testing things aren't happy (even without OpenMP) if they are different.

[ryandesign (Ryan Carsten Schmidt)]

Don't use "extract.suffix .tar.xz"; it is implied by "use_xz yes".

[eborisch (Eric A. Borisch)]

Any other concerns, or can I go ahead and patch? Other than the version bump, the only change when compiled without (+openmp) is making sure +/-assertions variant matches for clang/llvm. With +openmp, this also patches the toolchain and passes and adds a configure argument to find MacPorts' libomp such that '-fopenmp' works, as mentioned above.

It is more of a change than what was originally discussed on the mailing list, so I was waiting for feedback...

[eborisch (Eric A. Borisch)]

Planning to commit this soon if there are no objections...

[eborisch (Eric A. Borisch)]

Committed in r140577.

[mamoll (Mark Moll)]

The openmp variant doesn't compile on OS X 10.10 with Xcode 7.0. I also tried install the "vanilla" clang-3.7 port first and use that to compile clang-3.7+openmp, but that also fails. In both cases I get this error:

/opt/local/var/macports/build/_Users_mmoll_src_macports_dports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/bin/clang -arch x86_64 -dynamiclib -o /opt/local/var/macports/build/_Users_mmoll_src_macports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/asan_osx_dynamic/x86_64/libcompiler_rt.dylib
...
-stdlib=libc++ -lc++ -lc++abi -install_name @rpath/libclang_rt.asan_osx_dynamic.dylib -mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk

Sure enough, libc++ doesn't exist /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib. Instead, there's something called libc++.tbd. I guess this error will "fix itself" once El Cap is released.

[howarth.at.macports@…]

This issue still exists in Xcode 7.0.1. Wouldn't a possible fix be to install the symlinks for libc++.dylib and libc++abi.dylib in {prefix}/local/lib pointing at the copies in /usr/lib when Xcode 7 or later is installed?

[seanfarley (Sean Farley)]

The current solution is to install ld64 +xcode. That is what Jeremy suggests and it worked for me.