https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #4) > Also the fact that libc++ is using those APIs probably means they can't be > removed now. > > Does the same version of libstdc++.dylib need to work for both cases? See below... > There's already a generic implementation in terms of mutexes and condition > variables that works on Darwin today. ack (I do think that the conditional vars have some [likely pthread-related] issues on the oldest OS versions we support - but this change would not help that anyway). > But libstdc++ chooses the > implementation at build time and then it's fixed. If you need a single dylib > that supports old and new Darwin we'll need to dynamically check for > __ulock_wait and if it's not available, fallback to the portable code. That > would need some work. As of now, if we expect to build for a minimum deployment platform that is lower than the host, we would expect to build the target libraries for the minimum and against the SDK for that (and expect those libraries to work for a range of OS versions later than the minimum - usually that range is quite large). That would, perhaps, mean that if we build on 10.15 and deploy to 10.12 .. then then 10.15 platform would not be getting the smarter implementation - but I think that there are other compatibility improvements we could make to libstdc++ (e.g. the inline namespacing. allowing to use the system ABI lib, fixing once_call) that would be a better use of time than trying to make the selection of this facility dynamic (so it's certainly a nice-to-have, but not high on the priority list, so far). Alos, in practice, there are relatively few deployments that try this kind of thing, I'd expect the vast majority of macOS GCC to be self-builds for the current host only - and not expecting to ship built applications for wider deployment.
