ld64 +universal and llvm-X.Y -universal results in errors loading libLTO.dylib

[ryandesign (Ryan Carsten Schmidt)]

Parts of clang-3.2 are universal, even though I am not using the universal variant:

$ lipo -info /opt/local/libexec/llvm-3.2/bin/ld
Architectures in the fat file: /opt/local/libexec/llvm-3.2/bin/ld are: i386 x86_64 
$ port provides /opt/local/libexec/llvm-3.2/bin/ld
/opt/local/libexec/llvm-3.2/bin/ld is provided by: clang-3.2
$ port -v installed clang-3.2 llvm-3.2
The following ports are currently installed:
  clang-3.2 @3.2_0+analyzer+python27 (active) platform='darwin 9' archs='i386'
  llvm-3.2 @3.2_0 (active) platform='darwin 9' archs='i386'
$ 

This is a problem on x86_64 Leopard machines, because while i386 is the default build_arch, if an x86_64 part is in a binary, it will be used. What happens is that actually trying to use clang-3.2 to build another port fails:

dyld: Library not loaded: @executable_path/../lib/libLTO.dylib
  Referenced from: /opt/local/libexec/llvm-3.2/bin/ld
  Reason: no suitable image found.  Did find:
	/opt/local/libexec/llvm-3.2/bin/../lib/libLTO.dylib: mach-o, but wrong architecture
clang: error: unable to execute command: Trace/BPT trap
clang: error: linker command failed due to signal (use -v to see invocation)

I only tested the clang-3.2 port; the other versions are probably affected too.

[jeremyhu (Jeremy Huddleston Sequoia)]

ld is not provided by clang-3.2 nor llvm-3.2. It is provided by ld64. What is the output of:

port -v installed ld64

llvm-3.2 is providing libLTO.dylib.

[jeremyhu (Jeremy Huddleston Sequoia)]

ld64 should have a depends_lib on llvm-XX, so it shouldn't be building for x86_64 if llvm-XX isn't x86_64.

Oh, hmm... I think I see the problem. The *default* llvm will match arch, but that doesn't mean all llvm will... ugg...

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

ld is not provided by clang-3.2 nor llvm-3.2. It is provided by ld64. What is the output of:

port -v installed ld64

llvm-3.2 is providing libLTO.dylib.

Oh you're right. I was confused because:

$ port provides /opt/local/libexec/llvm-3.2/bin/ld
/opt/local/libexec/llvm-3.2/bin/ld is provided by: clang-3.2
$

But now I see:

$ ls -l /opt/local/libexec/llvm-3.2/bin/ld
lrwxrwxrwx  1 root  admin  26 Feb 23 10:47 /opt/local/libexec/llvm-3.2/bin/ld -> /opt/local/libexec/ld64/ld
$ port provides /opt/local/libexec/ld64/ld
/opt/local/libexec/ld64/ld is provided by: ld64
$ port -v installed ld64
The following ports are currently installed:
  ld64 @127.2_6+llvm31+universal (active) platform='darwin 9' archs='i386 x86_64'
$ 

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm not really sure how to solve this except to say that if ld64 is +universal, then all llvm-X.Y need to be +universal as well... there's no way to enforce that rule that I can see.

[larryv (Lawrence Velázquez)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Yeah, I realize now it's really only a problem on Leopard (and presumably Tiger), only when universal_archs have been changed from ppc i386 to x86_64 i386, and only when ld64 is installed universal and clang is not—an unusual combination of circumstances that I just happened to run into. In an ideal world we might fix this, but the days when everything on Tiger and Leopard are ideal have passed, so I'm ok with not fixing this.

[jeremyhu (Jeremy Huddleston Sequoia)]

It could still reproduce if llvm-X.Y is built i386 only and ld64 is x86_64 (or +universal), but that's also an unlikely scenario. Oh well...