Yes, we are talking about the libstdc++ that is shipped with gcc6. I should have made clear that a major downside of choice #2 is that it requires a library dependency on gcc6. That is something that most (the vast majority of?) users will not want. So perhaps choice #3 or choice #2 with the default variant only for systems prior to OS X Mavericks?
-Marcus > On Jan 31, 2017, at 1:53 PM, Mojca Miklavec <[email protected]> wrote: > > On 31 January 2017 at 19:48, Marcus Calhoun-Lopez wrote: >> >> 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++. > > Just to make sure: are we talking about libstdc++ 3 that is shipped with gcc6? > > > While I'm currently not yet sure how or when to use this, I don't see > a problem with #2. > > Making it a non-default variant is probably useless, making > "-stdlib=libstdc++" switch to libstdc++ from MP (option #1) is a > no-go, creating a subport and having an additional compiler (option > #3) sounds like an overkill. > > Unless this introduces undesired side-effects (which I don't believe > it does), I don't see the need for a variant. Unless the user does > something special and makes the extra effort to use a non-startand > flag -stdlib=macports-libstdc++, I guess that there won't be any > side-effects anywhere. So I see no harm in making this the default > once you do sufficient testing. > > Mojca
