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

[Jeremy Huddleston Sequoia]

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

> On Thu, Jan 17, 2013 at 12:25:57PM -0800, Jeremy Huddleston Sequoia wrote:
>> 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.
> 
> OK. Thanks for the explanation. There's some information I couldn't find
> on the libc++ website: It claims it supports C++11, but does that also
> mean I can build older C++ code against this library?

I'm not really an expert on C++ or libc++, so I can't really answer that, sorry.  I just understand more of the lower level linking, dynamic linking, etc.  I would advise you to just give it a try.

FWIW, I successfully built almost all of my base set of ports using libc++ as my default C++ runtime.  The only things that I have in my prefix using libstdc++ are webkit-gtk (because it fails with clang, not because of libc++/libstdc++ issues) and llvm-gcc42, so I'd say it's fairly safe for you to start testing with.

> If that's possible the only bit missing to be able to build everything
> against one library is forcing g++ to build and link against libc++.

The problem is that it will need to use libc++'s STL.  The symbol mangling is entirely different, and there are other issues.

>> The problem is that g++ doesn't support libc++ (AFAIK).
> 
> Oh, so that's the bit of information I was lacking, causing me to wonder
> why we tried to get this right with multiple C++ stdlib implementations.
> 
> However, other people seem to be facing the same problem, too, and it
> seems there _is_ a way to have g++ use libc++ (although I have not
> verified this):
> http://sylvestre.ledru.info/blog/sylvestre/2012/08/15/libc_new_c_standard_library_in_debian

Interesting.  I'll take a look, but if it's anything more than "apply these patches to gcc" I can't really touch it due to gcc being GPL3.

>> 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.
> 
> While that would theoretically work it still might be a problem for
> developers using MacPorts. Imagine lib A is built against libc++, lib B
> is built against libstdc++. Now a developer wants to write a tool T
> linking against lib A _and_ lib B.

Yep.  I didn't say it would be pretty, but we could have detection and a nice warning to users rather than weird linking failures due to missing symbols ... that would be less ugly =)