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