New clang/llvm ports

[Jeremy Huddleston]

On Nov 4, 2011, at 10:12 AM, Jeremy Huddleston wrote:

> 
> On Nov 4, 2011, at 1:18 AM, Michael Feiri wrote:
> 
>> 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.
> 
> Ok, go ahead.  Sooner rather than later is better.

Since Michael never did this, and these ports have been there a while, I'm guessing we should just keep these.  I personally never liked the naming without the "-", so I'm glad to be ditching that.  The lack of - and . characters makes those port names ambiguous.

> 
>>> 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.
> 
> You can update clang to prepend ${prefix}/libexec/llvm-${version}/lib to $DYLD_LIBRARY_FALLBACK_PATH before it exec's ld.  That will get ld to dlopen the desired libLTO.dylib.

Michael, did you ever get around to doing that?

> That seems much cleaner than using the symlink to get clang to exec ld from a different path.

Aside from the lto hack above, I haven't seen any issues reported.  llvm-3.0 release is scheduled for ~1 week from today.  I plan on adding a port select group for clang (should we have one for llvm as well) and deprecating the old ports shortly thereafter.

Speak up now...