Opened 7 months ago

Last modified 7 weeks ago

#53184 new defect

A cxx11-compatible clang compiler on 10.5 PPC ?Some progress...

Reported by: kencu (Ken) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: leopard powerpc Cc: jeremyhu (Jeremy Huddleston Sequoia), dbevans (David B. Evans)


We have been trying for a while now to get a current version of clang working on 10.5 - specifically PPC - and this ticket is keep a log of successes and failures in this regard. Jeremy's recent 10.5 fixes have enabled 10.5 Intel to have a working version of libc++ and clang-3.7 that can cross-compile simple PPC apps.

I have had some success with clang-3.6 on 10.5 PPC, so I thought I would document how that worked in case anyone would like to try it, or alternatively has some ideas how to better test it and/or improve the situation.

When I tried, I could not build libcxx on PPC with clang-3.4, but it does (as Jeremy documents) build with clang-3.4 on 10.5 Intel with PPC slices. I copied the following files built on the 10.5 Intel system


over to a 10.5 PPC machine, placing them into /opt/local/var/macports/incoming/verified, and then installed each one like this:

sudo port -v install PORTNAME +universal universal_arches="i386 ppc x86_64" supported_arches="i386 ppc x86_64"

I believe that was the full list of cross-compiled files that I had to move over.

Next, I tried to cross-compile clang-3.7 and clang-3.8 with ppc slices. LLVM-3.7 and 3.8 did build with ppc slices, but they segfault when moved to the 10.5 ppc machine with what appears to be an error in the address lookup for strlen(). Neither clang-3.7 nor clang-3.8 would cross-compile on 10.5 Intel, in each case delivering up error 12 during the link phase. Whether or not that can be overcome is to be discovered.

Back to the 10.5 PPC machine, clang-3.4 proved to be quite touchy compiling software, however with some modifications as below, it would compile llvm/clang-3.6 through to completion.

adding this to the clang-3.6 portfile

configure.cflags-append -fPIE
configure.cxxflags-append -fPIE
configure.ldflags-append -fPIE -nodefaultlibs -lc++ -lc++abi -lgcc_s.10.5
configure.ldflags-append -lSystem

and editing this to include ppc
    supported_archs i386 x86_64 ppc

updating macports.conf as usual

cxx_stdlib        libc++
buildfromsurce    always
delete_la_files   yes
default_compilers macports-clang-3.4 gcc-4.2

and installing clang-3.6 did go through to completion.

clang-3.6 @3.6.2_5+analyzer (active) platform='darwin 9' archs='ppc'
llvm-3.6 @3.6.2_4 (active) platform='darwin 9' archs='ppc'

clang-3.6 appears to work correctly

$ clang --version
clang version 3.6.2 (tags/RELEASE_362/final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix

and the llvm-binaries don't segfault (like the cross-compiled ones did)

$ /opt/local/bin/llvm-tblgen-mp-3.6 --version
  LLVM version 3.6.2
  Optimized build.
  Built Dec 29 2016 (18:30:54).
  Default target: powerpc-apple-darwin9.8.0
  Host CPU: 970

and so far simple apps build and link against libc++

$ helloworld
Hello World!

$ otool -L /opt/local/bin/helloworld
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 697.0.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.9.0)

and a few more complex apps also build and run

$ otool -L /opt/local/bin/nzbget
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/opt/local/lib/libgnutls.30.dylib (compatibility version 37.0.0, current version 37.8.0)
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.4.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 697.0.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.9.0)

$ nzbget --version
nzbget version: 14.1

at this time, clang-3.7 / llvm-3.7 will not build through on 10.5 PPC, and the cross-compiled llvm-3.7 segfaults on PPC.

Hope this helps someone. K

Attachments (1)

clang-3.9.ppc.32bit.10.5.libcxx.error.log (744.0 KB) - added by kencu (Ken) 2 months ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 7 months ago by dbevans (David B. Evans)

  • Cc dbevans added

comment:2 Changed 4 months ago by mf2k (Frank Schima)

  • Keywords powerpc added; PPC removed

comment:3 Changed 2 months ago by kencu (Ken)

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.

Changed 2 months ago by kencu (Ken)

comment:4 Changed 2 months ago by kencu (Ken)

And success in end, with clang-3.7, building it with gcc6, with this build line

sudo port -v install clang-3.7 configure.compiler=macports-gcc-6 supported_archs="ppc ppc64" build_arch="ppc"`
$ port -v installed clang-3.7
The following ports are currently installed:
  clang-3.7 @3.7.1_4+analyzer (active) platform='darwin 9' archs='ppc' date='2017-05-14T16:54:46-0700'


$ clang --version
clang version 3.7.1 (tags/RELEASE_371/final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix

Yeah, well. That is satisfying, to an extent. It built through to completion without errors, at least. Now to see if the bugs Jeremy points out on the LibcxxOnOlderSystems page are the same on this build, and to give it a test run.

Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:5 Changed 2 months ago by kencu (Ken)

building clang-3.8 with gcc6 also works, with one small error in the lipo script:

make[2]: Entering directory `/opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build'
[ 14%] Generating ../../../../lib/clang/3.8.1/lib/darwin/libclang_rt.10.4.a
cd /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/projects/compiler-rt/lib/builtins && /opt/local/bin/cmake -E make_directory /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/./lib/clang/3.8.1/lib/darwin
cd /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/projects/compiler-rt/lib/builtins && lipo -output /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/./lib/clang/3.8.1/lib/darwin/libclang_rt.10.4.a -create -arch i386 /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/lib/libclang_rt.builtins_i386_10.4.a -arch x86_64 /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/lib/libclang_rt.builtins_x86_64_10.4.a
fatal error: lipo: specifed architecture type (i386) for file (/opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/lib/libclang_rt.builtins_i386_10.4.a) does not match its cputype (18) and cpusubtype (0) (should be cputype (7) and cpusubtype (3))
make[2]: *** [lib/clang/3.8.1/lib/darwin/libclang_rt.10.4.a] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build'
make[1]: *** [projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.10.4.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 14%] Building CXX object tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangCommentCommandInfoEmitter.cpp.o

This probably is due to an assumption in the script that the build is on Intel, because this file is actually ppc code libclang_rt.builtins_i386_10.4.a and this is worked around quite easily by going into this folder:

cd /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/projects/compiler-rt/lib/builtins

And executing this slightly altered line:

sudo lipo -output /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/./lib/clang/3.8.1/lib/darwin/libclang_rt.10.4.a -create -arch ppc /opt/local/var/macports/build/_opt_peggedports_lang_llvm-3.8/clang-3.8/work/build/lib/libclang_rt.builtins_i386_10.4.a

That then gives you a completed installation of clang-3.8. llvm-3.8 also builds nicely through to completion using gcc6, so in the end we have success:

$ clang --version
clang version 3.8.1 (tags/RELEASE_381/final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.8/bin

We then have two clang compilers, 3.7 and 3.8, that work without segfaulting on 10.5 PPC. This was successful at building a fairly complex cxx11 port, aria2, with a build line like this:

sudo port -v install aria2 configure.compiler=macports-clang-3.7 configure.cxx_stdlib=libc++
$ port -v installed aria2
The following ports are currently installed:
  aria2 @1.31.0_0 (active) platform='darwin 9' archs='ppc' date='2017-05-14T18:21:11-0700'

which has proper linking against libc++:

$ otool -L /opt/local/bin/aria2c
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.4.0)
	/opt/local/lib/libgnutls.30.dylib (compatibility version 45.0.0, current version 45.2.0)
	/opt/local/lib/libnettle.6.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libgmp.10.dylib (compatibility version 14.0.0, current version 14.2.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 26935.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 697.0.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.9.0)

which runs, finds it's libraries, and appears to work normally so far, with limited testing:

$ aria2c
Specify at least one URL.
See 'aria2c -h'.
Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:6 Changed 2 months ago by kencu (Ken)

Trying to build some software such as aria2c with clang-3.8 on PPC runs into the standard missing llrintf long long types that were excluded from < 10.7, which we can also see on 10.6.

In file included from /opt/local/libexec/llvm-3.8/bin/../include/c++/v1/cmath:301:
/opt/local/libexec/llvm-3.8/bin/../include/c++/v1/math.h:1199:91: error: use of undeclared identifier 'llrintf'
inline _LIBCPP_INLINE_VISIBILITY long long llrint(float __lcpp_x) _NOEXCEPT       {return llrintf(__lcpp_x);}

Jeremy has fixed this error already, and it no longer shows up on 10.6. I suspect this is fixed in a slightly newer version of the clang-3.8 portfile.

Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:7 Changed 7 weeks ago by kencu (Ken)

On the niche clang-on-ppc front, comes some progress I wasn't certain would ever be possible.

Indeed however, clang-3.8 and llvm-3.8 do in the end build, install, and function to build and install working ports on 10.4 PPC Tiger without too much trouble.

$ port -v installed clang-3.8 llvm-3.8
The following ports are currently installed:
  clang-3.8 @3.8.1_8+analyzer (active) platform='darwin 8' archs='ppc' date='2017-06-03T16:14:41-0700'
  llvm-3.8 @3.8.1_3 (active) platform='darwin 8' archs='ppc' date='2017-06-03T01:16:16-0700'

$ clang --version
clang version 3.8.1 (tags/RELEASE_381/final)
Target: powerpc-apple-darwin8.11.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.8/bin

The same potholes about exceptions are likely still present -- although if backended with libstdc++ from gcc perhaps there will be better luck.

I've completed backporting the libgcc5abi compatability functions from clang-3.9+ into clang-3.8 with the kind help from Debian patches that did the heavy lifting, and also backed Marcus' macports-libstdc++ modifications into clang-3.8, so for the moment, the system can use libstdc++ from gcc6. Libc++ might be next.

The last linker in MacPorts for Tiger is ld-97, but a kind soul has already ported ld64 versions in the 200's to PPC, so hopefully we can get at least ld64-136 working, and maybe something newer.

Note: See TracTickets for help on using tickets.