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...
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
