llvm 2.5 port fails to support Link Time Optimization

[macports@…]

The port does not make libLTO.dylib avaliable to a linker. Thus -flto and -O4 do not work in llvm-gcc42.

Either provide a custom linker for use with llvm in macports or simply make libLTO.dylib available to the system linker by placing a symlink to /opt/local/lib/libLTO.dylib in /usr/lib/. The second option would make LTO/bitcode linking available globally but would leave the existing XCode llvm installation in /Developer/usr/ unaffected.

[ryandesign@…]

Is this still an issue with llvm 2.6?

[macports@…]

Yes, this is still an issue. The easiest way to test this is to compile something in llvm-gcc42 with "-O4". If libLTO.dylib is not accessible, the linker will complain that the object files (which are really bitcode files in this case) are not of the required architecture. I see several ways to fix this:

A) Install a symlink to /opt/local/lib/libLTO.dylib in /usr/lib/

B) Configure compilers with "--with-ld=/Developer/usr/bin/ld"

C) Install a symlink to /Developer/usr/bin/ld in /opt/local/libexec/gcc/i686-apple-darwin${os.major}/4.2.1/

D) Provide a custom  ld64 in macports and make it available in /opt/local/libexec/gcc/i686-apple-darwin${os.major}/4.2.1/

No option is really perfect. I'd say that D) would be the cleanest solution, but sadly that is not an option right now because the public ld64 sources seem to be  incomplete and unusable. I'm happily living with option A) for several months now under 10.5, but I understand that installing files outside the macports hierarchy is not welcome. Options B) and C) rely on the llvm libraries that come bundled with XCode >=3.1. But it strikes me that you end up using mismatched versions of llvm and libLTO.dylib this way. And option B), which is  what fink does in their llvm-gcc42 package, doesnt seem to work for clang.

I have attached diffs for option A) and option C) and verified that both approaches enable llvm-gcc and clang to compile with "-O4" when installed in the /opt/local hierarchy.

[macports@…]

Recently I tried to setup the llvm-gcc42 port to use /Developer/usr/bin/ld in Snow Leopard. It turned out that the mismatch between the different versions of llvm really does cause problems. It worked with llvm 2.6 and Leopard, but breaks with llvm 2.6 and Snow Leopard. This effectively kills option B) and C).

Now if we consider modifications outside of /opt/local to be prohibited then we are left with option D) as the only viable solution. I didnt realize there is already a port that provides a custom ld_classic/ld64 in macports: odcctools. That port looks severely outdated though and will suffer under the same inability to build the 10.6 version of ld64. But the 10.5 version of ld64 could be sufficient to support LTO.

So I guess the solution is D) to wait for a resurrection of the odcctools port with support for LTO and perhaps offer A) as an optional variant for the llvm port. I have attached a patch to introduce such a "global_lto" variant and filed #23580 to track the issue with odcctools.

[macports@…]

As mentioned in #23580, a solution for this issue (a usable port of ld64) and several related enhancements are available in #24112.

[mfeiri@…]

Fixed in r70475