Hi, To be blunt, i am not in favour of any of your proposals. I do not think we should have any update that allows builds to default to using macports stdlibc++. Old (ancient in my view) systems where the system c++ runtime is stdlibc++ should be allowed to die the graceful death they deserve. On other systems, when the system clang compiler does not support the features a specific port requires, then those ports can blacklist those compilers such that the macports clang compilers, using libc++, are preferred. Thats it, nothing else.
Chris > On 31 Jan 2017, at 6:48 pm, Marcus Calhoun-Lopez <mcalh...@macports.org> > wrote: > > In the recent mailing list discussion on C++11, there were no comments on the > specific aspects of the proposal > (https://lists.macports.org/pipermail/macports-dev/2017-January/thread.html#35173). > There is one aspect in particular that I would like to ask about: the > proposed changes to clang (https://trac.macports.org/ticket/53194). > Any comments would be greatly appreciated. > > There are three ways to allow clang to refer to MacPorts libstdc++. > > 1) Create a *default* variant to have -stdlib=libstdc++ refer to MacPorts > libstdc++. > This was quite rightly rejected because clang should be “as compatible > with the host as possible.” > I only bring it up because the required patch is simpler. > > 2) Create a new command switch -stdlib=macports-libstdc++ to refer to > MacPorts libstdc++. > > 3) Create a new subport clang-libstdcxx for which -stdlib=libstdc++ refers to > MacPorts libstdc++. > Again, a reason to do this is because the required patch is simpler. > > #2 is already in the development versions of clang > (https://github.com/macports/macports-ports/commit/c68d69b898fece7fea96b61ae0dd33650f628289 > and > https://github.com/macports/macports-ports/commit/49bd2ee7c1e54f290cb6fe07a084de8a2abddb66), > but for my purposes, the variant would have to be the default. > > Patches for all three proposal are attached to the ticket. > > Thank you, > Marcus