New clang/llvm ports

[Michael Feiri]

Am 01.11.2011 um 23:51 schrieb 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.

I like the overlay feature of macports to test unstable ports outside the main public repo. But this might be a matter of personal preference.

One thing I'd like to do while these ports are still "in the making" is to adjust the names to follow our usual scheme for versioned ports, e.g. gcc46, python27, scala29, etc.


> 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.

At this point there are just the llvm sub projects, ld64, pure, and the pyXX-llvm ports. See "port list depends:llvm" for the complete list.


>> 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...

Well, there is nothing to patch in llvm. It is up to the linker (ld64) to load the correct libLTO and perform link-time-optimizations. All you can do in llvm is to arrange a way for the linker to find the correct version of libLTO. And this is what a symlink in ${prefix}/libexec/llvm-${version}/ will achieve. I dont see a nice alternative.

Regards, Michael