Support for older MacOS systems

Runtimes C++
1

Hi all,

I'm helping to maintain the clang / llvm / libcxx / libcxxabi ports at MacPorts, mostly supporting the older systems, while Jeremy Huddleson takes the lead on that. We have a reasonably simple and largely automated method of installing libc++ on older systems, and optionally updating libc++ on all systems to a current version if people wish to do so.

We have enabled the -femulated-tls features in the llvm tree to supply thread_local support to 10.5 and 10.6 as well. The compilers are very functional, and do extremely well building a large percentage of current software -- MacPorts has about 20,000 active ports in the mix.

Recently when updating our ports to the release versions of llvm / clang / libcxx 8.0, I came across the block placed in the CMakeLists.txt file indicating anyone interested to report to the libcxx maintainers -- so here I am. The block was easily removed, and llvm-8.0 / clang-8.0 are rolled out on MacPorts for all Intel systems 10.5 and up. (PowerPC support actually works reasonably well also, but that's another tale).

I won't pretend these older systems represent some kind of large market share. It's hard to get sold statistics about how many systems are actively using these MacPorts-supplied features. But I can report that as soon as something breaks on these systems, people open tickets promptly about the issues, and we can usually fix them.

I think this keeps these machines doing useful tasks rather than just being junked. Many of us, like me, have bought quite a number of Apple machines over the years, and it's satisfying to see them still doing something rather than just bin them.

I certainly would not expect anyone at Apple or at llvm to spend any serious cycles on this -- but if the question is whether anyone would miss the support if it were just stripped out of the llvm tree, then there are at least some people who would miss it.

Best,

Ken Cunningham

2

So I was the one to initially put this "trap" in place because I was trying to eliminate technical debt whilst seeing who would be broken by removing old workarounds. I suspected nobody would be broken by that one because I didn't think people were still building libc++ from source on those old systems, but I was wrong. Thanks for reporting this.

Looking at the specific issue further, I think the current trunk version of libc++ should build on old systems just fine. Without the workaround, we'll be re-exporting the hard-coded list of symbols in libc++abi.v2.exp instead of all the symbols in the libc++abi.dylib, but those should be equivalent. Can you please comment on whether trunk seems to work for you?

Thanks,
Louis

3

Indeed clang-trunk and llvm-trunk build through to completion on all systems, 10.6 and up, including building libcxx during the clang build. I haven't tried the 10.5 trunk builds as yet.

We tend to lag a bit behind trunk with our libcxx releases, and currently we are installing libcxx 5.0.

I have installed libcxx 7.0 on my personal 10.6.8 systems to test it, and have found no notable issues with that version.

The only flags during testing are the minor ones expected from using -femulated-tls on Darwin, as it's not expected by the test suite for Darwin to be using cxa_thread_atexit as we are doing on those systems, instead of tlv_atexit.

I am often amazed at just how well it all works, and how something as complex as llvm, clang, and libcxx can build through on 10.5 or 10.6.8 with hardly a hiccup or compiler warning.

Kudos.

Ken