From owner-freebsd-toolchain@freebsd.org Wed Mar 16 22:36:13 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 145EEAD3CD3 for ; Wed, 16 Mar 2016 22:36:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0E89B12 for ; Wed, 16 Mar 2016 22:36:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::ecf9:a174:3b2:d2d8] (unknown [IPv6:2001:7b8:3a7:0:ecf9:a174:3b2:d2d8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 225462F330; Wed, 16 Mar 2016 23:36:09 +0100 (CET) Subject: Re: c++/libc++ help needed for chromium update Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160316212749.GA1426@squirrel.exwg.net> Date: Wed, 16 Mar 2016 23:36:01 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> References: <20160316212749.GA1426@squirrel.exwg.net> To: Christoph Moench-Tegeder X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 22:36:13 -0000 --Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder = wrote: >=20 > 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"). >=20 > The following is my interpretation, grain-of-salt applies. >=20 > There's one issue remaining: this line > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/int= ernal_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). >=20 > The scoped_ptr implementation is this one: > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/mem= ory/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/mov= e.h#35 >=20 > The key_data_pairs_ thing is a std::vector > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/int= ernal_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 >=20 > (I think you get the hang of it...) >=20 > 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 >=20 > 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 is: template 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) =3D 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::value && is_nothrow_copy_constructible::value) : first(__p.first), second(__p.second) { } #endif E.g. in the case of a trivial copy constructor, it is created with "=3D 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=3D1 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 --Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbp39gACgkQsF6jCi4glqNUGgCgxG++i1RjGLNNegbuojzbvM0p sn0AoN1o3Lsfjg7+EuKOhfAQD3/Rinhb =UqHN -----END PGP SIGNATURE----- --Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE--