On Sun, 8 Sep 2013 14:57:01 +0200 Dimitry Andric <d...@freebsd.org> wrote:
> On Sep 8, 2013, at 08:14, O. Hartmann <ohart...@zedat.fu-berlin.de> > wrote: > > On Sat, 7 Sep 2013 22:49:54 GMT > > rak...@freebsd.org wrote: > > > >> Synopsis: > >> devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: > >> call to 'swap' is ambiguous > >> > >> State-Changed-From-To: open->patched > >> State-Changed-By: rakuco > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > >> State-Changed-Why: > >> I don't think the previous version worked. > >> > >> From your description, it looks like you've switched to building > >> with libc++ whereas libstdc++ was being used before. > >> > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > >> 4.8.6 (but we've backported) will finally make Qt build with > >> libc++. > >> > >> We've just sent an exp-run request for Qt 4.8.5, and will hopefully > >> fix all these errors once it is committed. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > I build the world/kernel since early this year with > > > > CXXFLAGS+= -stdlib=libc++ > > CXXFLAGS+= -std=c++11 > > > > > > in /etc/src.conf. I do not use those flags > > in /etc/make.conf! /etc/src.conf is supposed to target ONLY > > the /usr/src world, not the ports - this is as I interpret the man > > page for /etc/src.conf and it would be logical. But this > > rule/thinking seems to be broken by some includes > > from /usr/ports/Mk ingredients. > > Since r255321, -stdlib=libc++ is effectively the default, at least > when you haven't set gcc as the default compiler. So it also applies > to ports, which unavoidably will lead to a bit of fallout. My > personal experience is that most C++-based ports compile fine with > libc++ instead of libstdc++, except for a few that rely on internal > libstdc++ details. > > However, -std=c++11 is *not* yet the default, and C++11 has different > rules here and there, so some ports might fail to compile due to this. > For some ports, too much hacking may be required to make them work > with C++11. So in case of trouble, try removing -std=, or setting it > to different values (c++0x, c++98, gnu++98, etc), to get the port to > compile. > > Note the base system should have no problems with -std=c++11, so > please continue to use the option in src.conf, and report any > problems if you encounter them, so we can fix them. :-) > I've been using clang and libc++ successfully on 9.1-RELEASE for quite some time now. Based on what I've learned, expect the following pitfalls that might hit you hard in production: - Bugs in in libc++: CURRENT is good about pulling in fixes, but there are still quite basic things getting fixed, e.g. cout/cerr not being thread safe (this was supposedly fixed in CURRENT and STABLE just a few weeks ago). Another example was handling std::vector<bool> incorrectly (ouch). Other problems only affect C++11/C++14 features and shouldn't be a big issue when porting. - Mixed C++ library linkage: For some ports autoconf/libtool might pull in libstdc++ by accident, you really don't want this to happen since std types don't match (e.g. std::exception and everything inheriting from it, which will break exception handling in client code). - Incompatibilities in corner cases of the language: A good example is the exception specification of destructors. Those are defaulting to noexcept(true) now, while in C++03 it's the opposite. Even though it's bad design in almost all cases, the language permits throwing from destructors in general. I got hit by that when porting devel/ice, which depends on databases/db5, which has no exception specification for destructors, but throws from them under certain circumstances (e.g. database close failed), in that specific case also from callbacks that were called from within db5. Overall the code was quite convoluted, but valid C++03. On top of that there are the usual incompatibilities between implementations (like iostreams in gcc 4.2's libstdc++ does some things differently then the imho more compliant libc++) and compile time problems (like the swap issue you experiences, those are easy to fix). So the bottom line is: When converting a port to use clang++ -std=c++11 -stdlib=libc++, the fact that it builds ok and runs a couple of unit tests without problems is not enough. Cheers, Michael -- Michael Gmelin _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
