Using -std=c++11 with the macports gcc-4.7 compiler

[Jeremy Huddleston Sequoia]

On Jan 17, 2013, at 12:12, Clemens Lang <cal at macports.org> wrote:

> On Thu, Jan 17, 2013 at 11:55:56AM -0800, Jeremy Huddleston Sequoia wrote:
> 
>> No. I'm saying that if a library uses libc++ and exports C++ objects,
>> then its client needs to use libc++ as well. Similarly, if a library
>> uses libstdc++ and exports C++ objects, then its client needs to use
>> libstdc++ as well.
> 
> So if both compilers _can_ generate ABI-compatible code, shouldn't we
> try to build all ports in MacPorts using the same ABI? Since the host's
> is the only one we can't change we should probably build for the host
> C++ stdlib?

In this case, there are two host C++ runtimes: the old libstdc++ (from gcc-4.2.1) and the new libc++ (llvm.org).  clang lets you choose which one you build against.

> So to achieve this we would have to make sure all C++ ports built with
> g++ use the host's libc++ (and also the matching set of headers, I
> guess)?

The problem is that g++ doesn't support libc++ (AFAIK).

>> No, because the machine used to build a project may not be the one
>> installing it.
> 
> But the most common case of that would be one of our buildbots, and we
> do know (or can easily look up) this information for them.

We're not really concerned with the buildbots here.  Those use all default configurations.  The issue here is with ports which use the macports-provided g++.

> Most problems we're dealing with on a daily basis are build failures
> when building locally, though, so having this readily available for the
> local system might already be an improvement over the current situation.

I'm thinking more along the lines of preventative analysis.  I'd rather have the potion to put into the record some notation of what C++ runtime the port is using, and if another port is linking against it, that port's Portfile can assert that their C++ runtime matches all their dependencies.