[libcxx-dev] Support for older MacOS systems

[Louis Dionne via libcxx-dev]

> On Mar 31, 2019, at 22:54, Ken Cunningham via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 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.

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