On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote: > I am not really following the issue, but I don't understand why what the > default C++ sublanguage is matters. It would seem that behavior should > be correct for any --std passed to compilers, per that sublanguages's > specification, and what you get by default is just what happens to you > if you don't pass --std. (And I basically think a build that does not > pass an explicit --std is buggy, but that's a separate issue.)
The problem is that this c++ lib does not support compiling with -std= for standards < C++11 (IIUC). This is pretty stupid, but IMHO no big deal. We can - expose max_align_t (bogusly) for older C++ versions and hope that every user of this combination is lucky with other parts of the lib - just not support (i.e. #error) on older C++ standard compiles - wait for Jörg to win the upstream battle and go with the fixed libc++ As a C++ developer in real life I would not expect much lossage from the #error variant - most things that really require older standards will have trouble anyway, and patching the few pkgsrc things that eroneously force some older C++ version (but actually do not care) is not a big deal. But I may be overoptimistic ;-) Michal, what I don't understand: what is the exact failure mode (i.e. what is a minimal sample to trigger the lossage)? Is max_align_t used in some header included everywhere, or just specific rarely used headers? Or is for example our in tree groff version not compilable with that libc++? Martin
