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? 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 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 > 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. -- Clemens Lang _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users