Requiring Mac OS >= 10.12 to build libc++.dylib

Hi,

This is a heads up that building the libc++ dylib on Mac OS will require Mac OS >= 10.12 once I land D74489. This will allow us to perform code simplifications in libc++, which is sorely needed because maintenance has become difficult with time. Please note that this only means that Mac OS >= 10.12 will be required to build the dylib.

If you are building the libc++ dylib on Mac OS < 10.12, please reach out so we can talk about a way forward.

Cheers,
Louis

Hi,

We do build libc++.dylib on MacPorts for users to install, currently on systems from 10.5 up, but some intrepid users have built it for 10.4.

Users have the option to replace their system installed libc++.dylib as well on 10.7+ if they choose to do so.

I was recently contemplating a way to co-install a newer libc++.dylib to use for MacPorts-installed software to build against to get newer libc++ features, but have not as yet embarked on that.

To build libc++ and libc++abi at present, Jeremy resuscitated the “buildit” and “testit” Makefiles so as to remove the need for a full cmake installation to bootstrap to libc++.dylib and to allow fine-grained tweaking, but moving to the monorepo and installing libc++ from there in the usual fashion is also a consideration.

For interest, we add the linux cxa_thread_atexit implementation to libc++abi.dylib for thread_local support on < 10.7, and it works quite nicely.

What part of the build is going to become 10.12+ only? If it’s a compiler issue, that is easy enough to work around. If it’s system infrastructure, not so easy…

I guess I’ll look at D74489 and see. This may cap out out libc++ offerings for older systems at 10.0 I suppose.

Best,

Ken

Oh, I see. It’s clock_gettime that we’ll be expecting from now onwards.

We do have a compatibility implementation of this for MacPorts already that we use when needed <https://github.com/macports/macports-legacy-support/blob/master/src/time.c> . I suppose I might leverage that implementation for older systems…

Ken

Oh, I see. It’s clock_gettime that we’ll be expecting from now onwards.

We do have a compatibility implementation of this for MacPorts already that we use when needed <https://github.com/macports/macports-legacy-support/blob/master/src/time.c> . I suppose I might leverage that implementation for older systems…

Ok, so it doesn’t look like a dealbreaker for you. LMK if I misunderstood.

Louis

It's been about a week and nobody has objected, so I'll make that change. We can always revert if something goes wrong.

Louis

SGTM.