New clang/llvm ports

[Jeremy Huddleston]

On Oct 28, 2011, at 12:17 AM, Michael Feiri wrote:

> I see you followed the advice to create versioned ports and to realize this by installing into subdirectories in ${prefix}/libexec/. I just didnt expect you'd go ahead and commit that to the main repository immediately. Well, I'll add myself as a co-maintainer.

Thanks.  I saw no reason not to commit to the main repo to get a wider audience.  The new ports don't interfere with the current ones.  Once we're done, we can obsolete the old ones.

Speaking of obsoleting the old ones, I'd like to do that sometime around when llvm-3.0 is releases (scheduled for Nov 16).  If developers of dependent ports could make an effort to test building and running against the new versioned llvm ports, that would be a big help.  Please report any issues you find.  You can use llvm-config-<llvm version> instead of llvm-config to get your CFLAGS, LDFLAGS, etc.

> One thing you missed is link-time-optimization. I briefly mentioned libLTO in our private discussion: The ld64 linker can not find libLTO.dylib in a subdirectory in ${prefix}/libexec. Thus it can not support link-time-optimization. Luckily ld64 searches libLTO.dylib relative to its location, even if it is executed through a symlink (see ticket #29173 for reference). My plan is to create a symlink to ld64 in ${prefix}/libexec/llvm-${version}/bin/ and to redirect the relevant compilers to use ld64 through that symlink. This will enable link-time-optimization using the matching version of libLTO. And it should be far safer than requiring a specific setting of an llvm port group (or a hypothetical llvm_select tool) or relying on a mismatched libLTO. Compilers that ignore this will simply not have LTO support.

I don't think this is the correct solution.  I'd rather patch llvm to search the correct location than use this symlink trick, but feel free to use this as a workaround for now...