On Jan 17, 2013, at 12:40, Clemens Lang <c...@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 =) _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
