#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