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.
>> 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.
That seems much cleaner than using the symlink to get clang to exec ld from a
different path.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
