[MacPorts] #51929: ld64-latest (and others?): default variant llvm38 breaks linking with pre-3.8-clang

[MacPorts]

#51929: ld64-latest (and others?): default variant llvm38 breaks linking with
pre-3.8-clang
--------------------------+------------------------
  Reporter:  ionic@…      |      Owner:  jeremyhu@…
      Type:  defect       |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  ld64-latest  |
--------------------------+------------------------

Comment (by ionic@…):

 I think number 2 is cleaner.

 To be fair, the old 0.0.0/0.0.0 behavior looks more like a bug than a
 carefully crafted compatibility-ensurance thing. It bites back for us,
 though.

 But should `ld` use an `llvm`-specific `libLTO` in the first place?
 Shouldn't the "MacPorts system version" link against the `libLTO` version
 as selected by the `llvm*` variant? We seem to replace the `llvm`-provided
 linker binaries with a symlink to the `ld64`-provided symlink in the first
 place to ensure that "our" system linker is used. Pulling in different
 `libLTO` binaries dependent upon which `clang` version is being used
 sounds... wrong?

-- 
Ticket URL: <https://trac.macports.org/ticket/51929#comment:3>
MacPorts <https://www.macports.org/>
Ports system for OS X