Opened 12 years ago

Closed 10 years ago

#19679 closed defect (fixed)

llvm 2.5 port fails to support Link Time Optimization

Reported by: macports@… Owned by: erickt@…
Priority: Normal Milestone:
Component: ports Version: 1.7.1
Keywords: llvm lto Cc:
Port: llvm llvm-gcc42

Description

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.

Attachments (3)

Portfile-llvm-A.diff (594 bytes) - added by macports@… 11 years ago.
Portfile-llvm-C.diff (687 bytes) - added by macports@… 11 years ago.
llvm-global_lto.diff (1.2 KB) - added by macports@… 11 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 12 years ago by mf2k (Frank Schima)

Cc: erickt@… removed
Owner: changed from macports-tickets@… to erickt@…

comment:2 Changed 11 years ago by ryandesign (Ryan Schmidt)

Is this still an issue with llvm 2.6?

Changed 11 years ago by macports@…

Attachment: Portfile-llvm-A.diff added

Changed 11 years ago by macports@…

Attachment: Portfile-llvm-C.diff added

comment:3 Changed 11 years ago by 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.

Changed 11 years ago by macports@…

Attachment: llvm-global_lto.diff added

comment:4 Changed 11 years ago by 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.

comment:5 Changed 10 years ago by macports@…

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

comment:6 Changed 10 years ago by mfeiri

Resolution: fixed
Status: newclosed

Fixed in r70475

Note: See TracTickets for help on using tickets.