c++/libc++ help needed for chromium update

[Dimitry Andric]

On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder <cmt at burggraben.net> wrote:
> 
> I'm currently working on updating www/chromium to the latest
> version (the 49 versions). Recently (that is, during development
> of version 49) the chromium developers allowed some c++11 features
> to be used.
> Included in those is std::move(), replacing their homegrown
> rvalue-reference-generating code (the .Pass() hack). That
> required me to use lang/clang36 as a compiler (with our
> clang 3.4.1 in FreeBSD 10 I got a bunch of obviously "wrong
> errors").
> 
> The following is my interpretation, grain-of-salt applies.
> 
> There's one issue remaining: this line
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/internal_api/public/data_batch_impl.cc#15
> causes an compiler error - complaining that a copy-assignment
> operator had to be used but the operator had been deleted (error
> message attached, it's a little unwieldy).
> 
> The scoped_ptr implementation is this one:
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/memory/scoped_ptr.h
> and the magic DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND()
> has been defined here:
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/move.h#35
> 
> The key_data_pairs_ thing is a std::vector<KeyAndData>
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/internal_api/public/data_batch_impl.h#41
> while KeyAndData is a std::pair<>
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/api/data_batch.h#18
> 
> (I think you get the hang of it...)
> 
> As clang is the "official" compiler used upstream, and after some
> research into C++ land (I'm from the plain C side), I'm suspecting
> that our libc++ is at fault (and it's behind upstream, of course,
> but there's no "simple" way of importing a new one - devel/libc++
> leaves the templates in /usr/include alone). Build results on
> FreeBSD 11 are still... building
> 
> Could anyone point me in a direction to resolve this?

While you are waiting for the FreeBSD 11 builds to complete, there are
maybe a few things you could try.

In r261801 [1], we turned off the _LIBCPP_TRIVIAL_PAIR_COPY_CTOR option
in libc++, because it made the ABI incompatible with the version of
libc++ we had shipped before that time.  However, this option makes the
std::pair copy constructor non-trivial, and this is a possible cause for
your compilation error.

The relevant part in <utility> is:

template <class _T1, class _T2>
struct _LIBCPP_TYPE_VIS_ONLY pair
{
[...]
#if !defined(_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS) && _LIBCPP_TRIVIAL_PAIR_COPY_CTOR
    _LIBCPP_INLINE_VISIBILITY
    pair(const pair& __p) = default;
#elif !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) || !_LIBCPP_TRIVIAL_PAIR_COPY_CTOR
    _LIBCPP_INLINE_VISIBILITY
    pair(const pair& __p)
        _NOEXCEPT_(is_nothrow_copy_constructible<first_type>::value &&
                   is_nothrow_copy_constructible<second_type>::value)
        : first(__p.first),
          second(__p.second)
    {
    }
#endif

E.g. in the case of a trivial copy constructor, it is created with "=
default", but otherwise it uses the copy constructors of the 'first' and
'second' members.  If these copy constructors are inaccessible or
deleted, as it looks like in this case, you will get an error about it.

The first thing you could try is to compile the Chromium source with
-D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 added to the flags.  This will
re-enable the trivial copy constructor for std::pair, but it is possibly
incompatible with precompiled libc++.so on your system.  Therefore,
things might break at runtime, in interesting ways.

Another thing you could try is to change the definition of scoped_ptr,
and comment out the deletion of its copy constructor.  However, I'm
unsure what side effects this may cause, as it is probably unwise to
copy scoped_ptrs.

Last but not least, please ask about this on the Chromium mailing lists.
There must be lots of C++ libraries out there with non-trivial std::pair
copy constructors, and they must have some sort of workaround for those.

-Dimitry

[1] http://svnweb.freebsd.org/changeset/base/261801

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20160316/38328eca/attachment.sig>