[MacPorts] #55709: libcxx @5.0.1_1 build fails with gcc

[MacPorts]

#55709: libcxx @5.0.1_1 build fails with gcc
---------------------+-------------------------------
  Reporter:  potmj   |      Owner:  jeremyhu
      Type:  defect  |     Status:  assigned
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.4.2
Resolution:          |   Keywords:  leopard universal
      Port:  libcxx  |
---------------------+-------------------------------

Comment (by potmj):

 Many thanks for everyones good thoughts on all this.

 From a macports user view, 5.0.1_0 compiled libc++ (& libc++abi)
 +universal with gcc 4.2, and 5.0.1_1 fails under some conditions, when
 they upgrade outdated.

 On 10.5, I think macports.conf  universal_arches defaults to "i386 ppc".
 It seems 10.5.8  executes ppc, i386, and x86_64, - at least for simple
 hello world tests.  I was testing [wiki:LibcxxOnOlderSystems] and had got
 all the way to a clang-3.7 that would build simple universals, with the
 exception of a broken libclang_rt.osx.a with ppc, until the bump to
 5.0.1_1.

 Being able to build libc++ with a convinent gcc in all cases, will remove
 dependencies and is helpful to bootstrap clang in a simple way (and those
 trying to cross compile for 10.4, etc).  Rebuilding libc++ later on with
 better optimization and/or additional arches, is always an option, at the
 cost of adding an extra step to the clang bootstrap.   I notice lots of
 the apple libraries are universal with 4 arches, so I guess that helps
 avoid having a missing arch at the bottom of a dependency chain.

 Even though libc++abi & libc++ are built with gcc, otool shows they are
 not dependent on libstdc.dylib

 Setting universal_arches to "i386 x86_64", as a temporary work around does
 get 5.0.1_1 built with gcc.

 I worry about upgrading ports, as the web of dependencies goes forever.
 With many old things installed +universal, upgrade often breaks, so having
 a tool chain with the same code generation ability as the old Xcode seems
 a good clang bootstrap goal. I agree with RJVB that you end up with
 +universal dependencies easily.  Even though they might be big, that would
 be OK, if they worked.  Hence a focus on having good +universal libraries.

 Thanks for pointing out the EXTRA_FLAGS variable.  My portfile skills are
 probably not up to working out why that line is now invoked in the wrong
 way for ppc code generation on intel.

 I noticed this WARNING flash past, so maybe this has further implications
 for the port....
 {{{
 buildit is no longer supported and will be removed in the next week!
 }}}
 This might be a problem, perhaps requiring the suggested move to a cmake
 that can be built with Xcode, or something.  I am sure Jeremy has a better
 understanding on the significance of this, I have no clue.

 Many thanks
 Michael

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