Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Aug 2019 23:46:52 +0200
From:      =?UTF-8?B?VMSzbA==?= Coosemans <tijl@FreeBSD.org>
To:        Konstantin Belousov <kostikbel@gmail.com>, gecko@FreeBSD.org
Cc:        Dimitry Andric <dim@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Marshall Clow <mclow.lists@gmail.com>
Subject:   Re: svn commit: r351253 - in head/contrib/libc++: include src
Message-ID:  <20190821234652.0ed2f345@FreeBSD.org>
In-Reply-To: <20190821155231.GQ71821@kib.kiev.ua>
References:  <201908201739.x7KHdXvv054610@repo.freebsd.org> <20190821144908.7137e6bc@FreeBSD.org> <20190821155231.GQ71821@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Aug 2019 18:52:31 +0300 Konstantin Belousov
<kostikbel@gmail.com> wrote:
> On Wed, Aug 21, 2019 at 02:49:08PM +0200, T=C4=B3l Coosemans wrote:
>> On Tue, 20 Aug 2019 17:39:33 +0000 (UTC) Dimitry Andric
>> <dim@FreeBSD.org> wrote: =20
>>> Author: dim
>>> Date: Tue Aug 20 17:39:32 2019
>>> New Revision: 351253
>>> URL: https://svnweb.freebsd.org/changeset/base/351253
>>>=20
>>> Log:
>>>   Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
>>>  =20
>>>     Rework recursive_timed_mutex so that it uses __thread_id instead of
>>>     using the lower-level __libcpp_thread_id. This is prep for fixing
>>>     PR42918. Reviewed as https://reviews.llvm.org/D65895
>>>  =20
>>>   Pull in r368916 from upstream libc++ trunk (by Marshall Clow):
>>>  =20
>>>     Fix thread comparison by making sure we never pass our special 'not=
 a
>>>     thread' value to the underlying implementation. Fixes PR#42918.
>>>  =20
>>>   This should fix std::thread::id::operator=3D=3D() attempting to call
>>>   pthread_equal(3) with zero values.
>>>  =20
>>>   Reported by:	andrew@tao11.riddles.org.uk
>>>   PR:		239038, 239550
>>>   MFC after:	3 days
>>>=20
>>> Modified:
>>>   head/contrib/libc++/include/__threading_support
>>>   head/contrib/libc++/include/mutex
>>>   head/contrib/libc++/include/thread
>>>   head/contrib/libc++/src/mutex.cpp
>>>=20
>>> Modified: head/contrib/libc++/include/__threading_support
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>>> --- head/contrib/libc++/include/__threading_support	Tue Aug 20 17:00:31=
 2019	(r351252)
>>> +++ head/contrib/libc++/include/__threading_support	Tue Aug 20 17:39:32=
 2019	(r351253)
>>> @@ -13,6 +13,7 @@
>>> =20
>>>  #include <__config>
>>>  #include <chrono>
>>> +#include <iosfwd>
>>>  #include <errno.h>
>>> =20
>>>  #ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
>>> @@ -392,6 +393,86 @@ int __libcpp_tls_set(__libcpp_tls_key __key, void =
*__p
>>>  }
>>> =20
>>>  #endif // !_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL || _LIBCPP_BUILDING_THR=
EAD_LIBRARY_EXTERNAL
>>> +
>>> +class _LIBCPP_TYPE_VIS thread; =20
>>=20
>> This seems to break building Firefox:
>>=20
>> In file included from /usr/ports/www/firefox/work/firefox-68.0.2/media/m=
transport/nricectx.cpp:82:
>> In file included from /usr/ports/www/firefox/work/firefox-68.0.2/media/m=
transport/third_party/nICEr/src/stun/stun_client_ctx.h:41:
>> In file included from /usr/ports/www/firefox/work/firefox-68.0.2/media/m=
transport/third_party/nICEr/src/stun/stun.h:45:
>> In file included from /usr/include/net/if_var.h:84:
>> /usr/include/sys/lock.h:68:15: error: reference to 'thread' is ambiguous
>>                             struct thread **owner);
>>                                    ^
>> /usr/include/sys/lock.h:42:8: note: candidate found by name lookup is 't=
hread'
>> struct thread;
>>        ^
>> /usr/include/c++/v1/__threading_support:397:24: note: candidate found by=
 name
>>       lookup is 'std::__1::thread'
>> class _LIBCPP_TYPE_VIS thread;
>>                        ^
>>=20
>>=20
>> This "class thread" conflicts with "struct thread" in sys/lock.h.
>> Should everything in sys/lock.h be under #ifdef _KERNEL? =20
> Why does firefox pulls if_var.h at all ?  (As I understand, this is how
> the pollution occurs.)

Right, it turns out it doesn't need it:

--- media/mtransport/third_party/nICEr/src/stun/stun.h.orig     2019-08-13 =
18:06:44 UTC
+++ media/mtransport/third_party/nICEr/src/stun/stun.h
@@ -41,7 +41,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O
 #include <sys/socket.h>
 #ifndef LINUX
 #include <net/if.h>
-#if !defined(__OpenBSD__) && !defined(__NetBSD__)
+#if !defined(__OpenBSD__) && !defined(__NetBSD__) && !defined(__FreeBSD__)
 #include <net/if_var.h>
 #endif
 #include <net/if_dl.h>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190821234652.0ed2f345>