Handling C++11

[Marcus Calhoun-Lopez]

I think perhaps I am not being clear in what I am proposing.

Currently, if cxx_stdlib is equal to libstdc++ then the cxx11PortGroup returns an error and the port does not build.
I am simply proposing that instead of returning an error, the port build instead.
In other words, the change is meant to respect whatever value cxx_stdlib is.

I am not proposing any changes to anyone’s configuration.
I am not proposing any changes to the buildbots.

If cxx_stdlib is equal to libc++, the end user would see no changes, not even revbumps.
If cxx_stdlib is equal to libstdc++, the only change would be that ports that didn’t build before would suddenly start (hopefully).

Please forgive me if I am not understanding the concerns, but this change is meant to affect *only* ports that are currently not building at all
for users who have elected to have cxx_stdlib be equal to libstdc++.

-Marcus

> On Jan 17, 2017, at 8:07 PM, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
> 
> Well, the entire c++ library on the buildbot would have to be rebuilt
> against libgcc's libstdc++ for this to work -- all of octave's deps
> and deps of deps would need to be built the same as octave, of course,
> and so everything else too. The whole machine has to be configured the
> same way (which is why intel appears to have funded the libgcc
> extensions when some linux distros went with defaulting to libgcc5+,
> making clang/llvm non-functional on those distros until they fixed
> it).
> 
> In the end, you would seem to wind up in a similar situation as we're
> in now with libc++ on these older machines.
> 
> I guess I'm struggling with the benefit of doing this over either
> fixing the metadata problem in archives and hosting libc++ files on
> the buildbots, or just defaulting to libc++ on these older machines if
> we're ready for that.