[MacPorts] #59717: clang >= 3.4: Unable to build/bootstrap on Intel Tiger

Sat Feb 8 21:23:02 UTC 2020

#59717: clang >= 3.4: Unable to build/bootstrap on Intel Tiger
-------------------------------------------------+-------------------------
  Reporter:  dgelessus                           |      Owner:  (none)
      Type:  defect                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:  tiger i386
      Port:  libcxx llvm-3.4 clang-3.4 llvm-3.7  |
  clang-3.7                                      |
-------------------------------------------------+-------------------------
Description changed by dgelessus:

Old description:

> It is currently not possible to build clang-3.4 or newer on Intel Tiger.
> As a result, any ports that require C++11 cannot be built on Tiger,
> because MacPorts selects a recent clang (currently 9.0) when looking for
> a C++11-capable compiler.
>
> This issue is somewhat complex because a lot of bootstrapping is
> involved, and multiple ports in the bootstrap process don't work properly
> on Tiger. The (simplified) bootstrap dependency chain looks like this:
>
> * Xcode 2.5 gcc
> * apple-gcc42
> * clang-3.4
> * libcxx
> * clang-3.7
> * newer clang (e. g. 9.0)
>
> So far I've run into the following individual issues in the chain:
>
> * (no longer applies) clang-3.4 requires libxml2 to build, which requires
> icu. icu requries a C++11 compiler, and MacPorts selects clang-3.4 here,
> which leads to a circular dependency.
>   * The clang-3.4 Portfile already has a special case to handle this
> issue, but it doesn't get triggered on Tiger, because the cxx_stdlib is
> set to libstdcxx and not libcxx.
>   * I've submitted a fix for this as [https://github.com/macports
> /macports-ports/pull/5771 PR 5771].
>   * This has been fixed by @kencu in [https://github.com/macports
> /macports-ports/commit/57b34213865ed6dd99e22c61f3721232ffccf2f9 commit
> 57b3421], by disabling the parts of clang-3.4 and clang-3.7 that require
> libxml2.
> * llvm/clang-3.7 always wants libcxx as its C++ stdlib, but the libcxx
> port doesn't support Tiger.
>   * I've attempted to make libcxx build on Tiger in
> [https://github.com/dgelessus/macports-ports/tree/tiger_libcxx_no_pr a
> branch of my fork]. This isn't tested very well yet. (I've previously
> submitted this as [https://github.com/macports/macports-ports/pull/5783
> PR 5783], but these changes likely won't be merged into the main ports
> tree, to avoid breaking newer systems.)
>   * Perhaps an alternative fix would be to make clang use libstdcxx
> instead of libcxx on Tiger. I haven't looked into this further yet, but
> @kencu has [https://github.com/kencu/TigerPorts/tree/master/lang/llvm-3.8
> a customized llvm/clang-3.8 port that uses libstdcxx], so it seems to be
> possible.
> * llvm-3.7's configure script tries to call clang-3.4 with the option
> -stdlib=macports-libstdc++, which that version of the clang port doesn't
> support. This option is patched in by MacPorts for clang-5.0 and newer
> with the +libstdcxx variant (which is enabled by default). clang ports
> older than 5.0 (including 3.4) don't have a +libstdcxx variant.
>   * This is caused by a bug in MacPorts base, which has been reported in
> #59584.
>   * As a workaround, the +libstdcxx patch from clang-5.0 can be applied
> to clang-3.4 (with minor modifications). This won't result in proper
> macports-libstdc++ support (because clang before 3.8 doesn't support
> compiling C++11 code against libstdc++), but it is enough to make the
> incorrect call from the configure script not fail.
> * llvm-3.7 references a couple of macros that don't exist on Tiger.
>   * This only requires some very minor patches, which I can submit once
> I've tested them.
> * The clang-3.7 build fails to build the compiler-rt libraries for the
> clang_darwin target (the clang_macho_embedded ones get built properly).
> make thinks that there is nothing to be done for the clang_darwin target,
> so no libraries are built, which causes later parts of the build (that
> expect the libraries to exist) to fail.
>   * This appears to be a similar issue to #54836 and #59157.
> * There may be more issues after this; I'm currently working on getting
> clang-3.7 fully built.
>
> I've already discussed some of these issues separately on IRC and GitHub
> (thanks to @jmroot and @kencu for the help so far!). This ticket is meant
> to be an overview of how the issues are related, as the issues further
> down the list usually can't be observed without first fixing/working
> around the previous issues.
>
> Also I'm not sure what the best solutions are for some of the issues, or
> if it even makes sense to use clang (rather than gcc) as the C++11
> compiler on Tiger. Any opinions and suggestions are welcome.

New description:

 It is currently not possible to build clang-3.4 or newer on Intel Tiger.
 As a result, any ports that require C++11 cannot be built on Tiger,
 because MacPorts selects a recent clang (currently 9.0) when looking for a
 C++11-capable compiler.

 This issue is somewhat complex because a lot of bootstrapping is involved,
 and multiple ports in the bootstrap process don't work properly on Tiger.
 The (simplified) bootstrap dependency chain looks like this:

 * Xcode 2.5 gcc
 * apple-gcc42
 * clang-3.4
 * libcxx
 * clang-3.7
 * icu
 * libxml2
 * cmake
 * newer clang (e. g. 9.0)

 So far I've run into the following individual issues in the chain:

 * (no longer applies) clang-3.4 requires libxml2 to build, which requires
 icu. icu requries a C++11 compiler, and MacPorts selects clang-3.4 here,
 which leads to a circular dependency.
   * The clang-3.4 Portfile already has a special case to handle this
 issue, but it doesn't get triggered on Tiger, because the cxx_stdlib is
 set to libstdcxx and not libcxx.
   * I've submitted a fix for this as [https://github.com/macports
 /macports-ports/pull/5771 PR 5771].
   * This has been fixed by @kencu in [https://github.com/macports
 /macports-ports/commit/57b34213865ed6dd99e22c61f3721232ffccf2f9 commit
 57b3421], by disabling the parts of clang-3.4 and clang-3.7 that require
 libxml2.
 * llvm/clang-3.7 always wants libcxx as its C++ stdlib, but the libcxx
 port doesn't support Tiger.
   * I've attempted to make libcxx build on Tiger in
 [https://github.com/dgelessus/macports-ports/tree/tiger_libcxx_no_pr a
 branch of my fork]. This isn't tested very well yet. (I've previously
 submitted this as [https://github.com/macports/macports-ports/pull/5783 PR
 5783], but these changes likely won't be merged into the main ports tree,
 to avoid breaking newer systems.)
   * Perhaps an alternative fix would be to make clang use libstdcxx
 instead of libcxx on Tiger. I haven't looked into this further yet, but
 @kencu has [https://github.com/kencu/TigerPorts/tree/master/lang/llvm-3.8
 a customized llvm/clang-3.8 port that uses libstdcxx], so it seems to be
 possible.
 * llvm-3.7 references a couple of macros that don't exist on Tiger.
   * This only requires some very minor patches, which can be found in
 [https://github.com/dgelessus/macports-ports/tree/llvm_3_7_tiger my fork's
 llvm_3_7_tiger branch].
 * The clang-3.7 build fails to build the compiler-rt libraries for the
 clang_darwin target (the clang_macho_embedded ones get built properly).
 make thinks that there is nothing to be done for the clang_darwin target,
 so no libraries are built, which causes later parts of the build (that
 expect the libraries to exist) to fail.
   * This appears to be a similar issue to #54836 and #59157.
   * This is also fixed in [https://github.com/dgelessus/macports-
 ports/tree/llvm_3_7_tiger my fork's llvm_3_7_tiger branch].
 * The configure script of icu tries to call clang-3.4 with the option
 -stdlib=macports-libstdc++, even though icu will be built against libc++
 (via the clang_dependency 1.0 portgroup). This option is patched in by
 MacPorts for clang-5.0 and newer with the +libstdcxx variant (which is
 enabled by default). clang ports older than 5.0 (including 3.4) don't have
 a +libstdcxx variant and do not support -stdlib=macports-libstdc++.
   * The incorrect compiler call is caused by a bug in MacPorts base, which
 has been reported in #59584.
   * As a workaround, the +libstdcxx patch from clang-5.0 can be applied to
 clang-3.4 (with minor modifications). This won't result in proper
 macports-libstdc++ support (because clang before 3.8 doesn't support
 compiling C++11 code against libstdc++), but it is enough to make the
 incorrect call from the configure script not fail.

 I've already discussed some of these issues separately on IRC and GitHub
 (thanks to @jmroot and @kencu for the help so far!). This ticket is meant
 to be an overview of how the issues are related, as the issues further
 down the list usually can't be observed without first fixing/working
 around the previous issues.

 Also I'm not sure what the best solutions are for some of the issues, or
 if it even makes sense to use clang (rather than gcc) as the C++11
 compiler on Tiger. Any opinions and suggestions are welcome.

--

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