[MacPorts] #53184: A cxx11-compatible clang compiler on 10.5 PPC ?Some progress...

[MacPorts]

#53184: A cxx11-compatible clang compiler on 10.5 PPC ?Some progress...
---------------------+-----------------------------
  Reporter:  kencu   |      Owner:  kencu
      Type:  defect  |     Status:  assigned
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:  leopard powerpc
      Port:          |
---------------------+-----------------------------

Comment (by kencu):

 Sadly, Iain's fixes don't fix the build of `compiler_rt`. (BTW, I found
 his patches apply cleanly to `clang-3.8`, but not to `clang-3.9`, for
 anyone who wants to test it.)

 The problem is most likely right at the premise of how the CMake logic in
 `compiler_rt` works, I think. It tries to do a test-compile of a `hello,
 world` program with different archs to see if a target can be built. But
 this doesn't work with `gcc6` and presumably other `gcc` versions. If you
 pass `gcc6` that can build only `ppc` and `ppc64` a build line like this:
 {{{
 gcc -arch i386 -o helloworld helloworld.c
 }}}
 It does not generate an error -- instead, it helpfully lets you know in a
 message that it assumes you had a stroke or something, passed it `-arch
 i386` by accident, and it builds it anyway, but using what I presume is
 the `host` arch, and you get a `ppc` executable.

 CMake apparently doesn't notice this detail, so it registers the `i386`
 build a success, adds it to the list of `archs`, and same with `x86_64`.
 So you wind up, in the end, with two identical binaries, both in actual
 fact `ppc` binaries, one labelled `i386` and one labelled `x86_64`.

 And that is where the lipo stage above errors out, because it has no idea
 what is going on now.

 At least I think I know what the problem is now :> Maybe this will lead to
 a fix once I understand how to fix that.

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