Opened 12 years ago

Closed 11 years ago

#38177 closed defect (wontfix)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: larryv (Lawrence Velázquez)
Port: ld64

Description

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.

Change History (8)

comment:1 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Port: ld64 added; clang-3.2 removed
Status: newassigned

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.

comment:2 Changed 12 years ago by 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...

comment:3 in reply to:  1 Changed 12 years ago by 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'
$ 

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

comment:5 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Summary: clang-3.2 builds parts universal when not asked told64 +universal and llvm-X.Y -universal results in errors loading libLTO.dylib

comment:6 Changed 11 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

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

comment:8 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: wontfix
Status: assignedclosed

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...

Note: See TracTickets for help on using tickets.