[MacPorts] #53931: clang's ld doesn't recognise "-lto_library" flag on 10.6

MacPorts noreply at macports.org
Sun Apr 30 08:06:13 UTC 2017


#53931: clang's ld doesn't recognise "-lto_library" flag on 10.6
-------------------------------------------------+-------------------------
  Reporter:  mojca                               |      Owner:  jeremyhu
      Type:  defect                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:  snowleopard
      Port:  clang-3.9 clang-4.0 llvm-3.9        |
  llvm-4.0                                       |
-------------------------------------------------+-------------------------

Comment (by mojca):

 Replying to [comment:16 kencu]:
 > First I tried changing the default ld64 to ld64-236 in the ld64
 Portfile, but ld64-236 has a dependency on clang-3.4 to build, and
 clang-3.4 had a dependency on ld64 to build, so ld64-236 cannot be the
 default on 10.6.

 OK, that's what I suspected.

 > So the simple step to enable 10.6 to run clang-3.9 is to first run `sudo
 port -v install ld64-236`, which will in fact build through to completion
 on an unmodified 10.6 system.
 >
 > ld64-latest has an amazing amount of build deps on 10.6, including
 llvm/clang 3.7, 3.8, AND 3.9, and I didn't start that build process
 running but I see no reason why it shouldn't complete once started.

 I suspect the large number of dependencies is due to trying to avoid
 dependency cycles.

 > is it possible to set something like `ld64-236 or newer` as runtime
 dependency for clang-3.9?

 What I didn't test yet is whether it's enough to have `ld64-236` installed
 or whether you actually need `ld64 +ld64_236`. If it's enough to just
 install `ld64-236`, I would indeed try adding that as a runtime dependency
 to clang 3.9. What I'm not sure about is whether it's possible to define
 "one or the other" as a runtime dependency in a way that won't kill us in
 cycles.

 I feel like we need some better way to handle circular dependencies in
 cases when a compiler can build a newer version of itself.

--
Ticket URL: <https://trac.macports.org/ticket/53931#comment:17>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list