[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:
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:  leopard powerpc
      Port:          |
---------------------+-----------------------------

Comment (by kencu):

 I continue to attempt to make progress on this issue trying to get a
 current clang on ppc. I have taken a new approach, of trying to build llvm
 and clang-3.[89] using gcc6, with some success.  Once the prerequisites
 have been built with ppc slices on Leopard intel and moved over to the
 Leopard PPC machine, the following can work: a build line something like
 this
 {{{
 sudo port -v install llvm-3.9 configure.compiler=macports-gcc-6
 supported_archs="ppc ppc64"
 }}}
 results in success with llvm versions:
 {{{
 $ port -v installed | grep llvm
   cctools @886_6+llvm33 (active) platform='darwin 9' archs='ppc'
 date='2016-10-22T10:49:21-0700'
   ld64-127 @127.2_8+llvm33 (active) platform='darwin 9' archs='ppc'
 date='2016-11-08T21:00:26-0800'
   llvm-3.3 @3.3_10 (active) platform='darwin 9' archs='ppc'
 date='2016-10-02T17:27:59-0700'
   llvm-3.4 @3.4.2_11 (active) platform='darwin 9' archs='ppc'
 date='2016-10-02T17:32:34-0700'
   llvm-3.6 @3.6.2_4 (active) platform='darwin 9' archs='ppc'
 date='2016-12-29T19:47:09-0800'
   llvm-3.8 @3.8.1_0 (active) platform='darwin 9' archs='ppc'
 date='2017-01-06T17:43:28-0800'
   llvm-3.9 @3.9.1_3 (active) platform='darwin 9' archs='ppc'
 date='2017-05-13T17:01:21-0700'
   llvm_select @2_0 (active) platform='darwin 9' archs='noarch'
 date='2016-10-02T00:18:02-0700'
 }}}
 clang is more difficult to build, and I haven't been able to get past a
 build of clang-3.6 built with clang-3.4 on ppc.

 Libomp has no ppc architecture targets, only ppc64, which is one hiccup.
 Rebuilding everything as ppc64 is probably what I will come to do in the
 end (as ppc64 has been fairly actively worked on compared to ppc32). To
 get around that, there is an option in clang's build to link against
 libgomp instead, which builds fine on ppc.

 I'm currently running into a strange error during the clang build that has
 also been noted on the linux forums when building clang for ppc:
 {{{
 In file included from
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/__mutex_base:15:0,
                  from
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/condition_variable:111,
                  from
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/src/condition_variable.cpp:14:
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/chrono:
 In function 'void std::__1::this_thread::sleep_for(const
 std::__1::chrono::duration<_Rep, _Period>&)':
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/thread:446:73:
 in constexpr expansion of 'std::__1::chrono::duration<long
 double>(std::__1::chrono::duration<_Rep, _Period>::max<long long int,
 std::__1::ratio<1ll, 1000000000ll> >(), 0u)'
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/chrono:560:64:
 in constexpr expansion of
 'std::__1::chrono::duration_cast<std::__1::chrono::duration<long double>,
 long long int, std::__1::ratio<1ll, 1000000000ll> >(__d)'
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/chrono:413:67:
 in constexpr expansion of
 'std::__1::chrono::__duration_cast<std::__1::chrono::duration<long long
 int, std::__1::ratio<1ll, 1000000000ll> >, std::__1::chrono::duration<long
 double>, std::__1::ratio<1ll, 1000000000ll>, true,
 false>().std::__1::chrono::__duration_cast<_FromDuration, _ToDuration,
 _Period, true, false>::operator()<std::__1::chrono::duration<long long
 int, std::__1::ratio<1ll, 1000000000ll> >, std::__1::chrono::duration<long
 double>, std::__1::ratio<1ll, 1000000000ll> >(__fd)'
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/clang-3.9/work/llvm-3.9.1.src/projects/libcxx/include/chrono:374:59:
 error: '(9.223372036854775807e+18 / 1.0e+9)' is not a constant expression
                             static_cast<_Ct>(__fd.count()) /
 static_cast<_Ct>(_Period::den)));
 }}}
 I'm not sure how to work around that error just now. There is an option
 during the clang build to build against libstdxx instead of libcxx, not
 the same thing as the modification Marcus made, but perhaps in some way
 similar - it's used on MSVC.

 I'll put up the  clang-3.9.ppc32 build log in case someone becomes curious
 about it.

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