Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

On Sun, 8 Sep 2013 14:57:01 +0200
Dimitry Andric <dim_at_FreeBSD.org> wrote:

> On Sep 8, 2013, at 08:14, O. Hartmann <ohartman_at_zedat.fu-berlin.de>
> wrote:
> > On Sat, 7 Sep 2013 22:49:54 GMT
> > rakuco_at_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