Feedback on clang change (#53194)
jonesc at hep.phy.cam.ac.uk
Tue Jan 31 20:35:49 UTC 2017
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.
> On 31 Jan 2017, at 6:48 pm, Marcus Calhoun-Lopez <mcalhoun at macports.org> wrote:
> In the recent mailing list discussion on C++11, there were no comments on the specific aspects of the proposal
> 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
> but for my purposes, the variant would have to be the default.
> Patches for all three proposal are attached to the ticket.
> Thank you,
More information about the macports-dev