On Wed, Aug 21, 2019 at 6:20 AM Tijl Coosemans <t...@freebsd.org> wrote:
> On Wed, 21 Aug 2019 15:07:56 +0200 Dimitry Andric <d...@freebsd.org> > wrote: > > On 21 Aug 2019, at 14:49, Tijl Coosemans <t...@freebsd.org> wrote: > >> On Tue, 20 Aug 2019 17:39:33 +0000 (UTC) Dimitry Andric > >> <d...@freebsd.org> wrote: > >>> Author: dim > >>> Date: Tue Aug 20 17:39:32 2019 > >>> New Revision: 351253 > >>> URL: https://svnweb.freebsd.org/changeset/base/351253 > >>> > >>> Log: > >>> Pull in r368867 from upstream libc++ trunk (by Marshall Clow): > >>> > >>> 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 > >>> > >>> Pull in r368916 from upstream libc++ trunk (by Marshall Clow): > >>> > >>> Fix thread comparison by making sure we never pass our special 'not > a > >>> thread' value to the underlying implementation. Fixes PR#42918. > >>> > >>> This should fix std::thread::id::operator==() attempting to call > >>> pthread_equal(3) with zero values. > > ... > >> This seems to break building Firefox: > >> > >> In file included from > /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/nricectx.cpp:82: > >> In file included from > /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/third_party/nICEr/src/stun/stun_client_ctx.h:41: > >> In file included from > /usr/ports/www/firefox/work/firefox-68.0.2/media/mtransport/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 > 'thread' > >> 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; > >> ^ > >> > >> This "class thread" conflicts with "struct thread" in sys/lock.h. > >> Should everything in sys/lock.h be under #ifdef _KERNEL? > > > > Maybe, but is Firefox using "using namespace std;" here? It is a likely > > explanation for the ambiguity between the global struct thread from > > sys/lock.h, and std::thread from libc++. > > Yes, several headers in media/mtransport/third_party/nICEr/src start > with: > > #ifdef __cplusplus > using namespace std; > extern "C" { > #endif /* __cplusplus */ > libc++ has always had a `std::thread` struct. The change here is that forward declaration moved from <thread> to <__threading_support>, and that was included by <mutex>. -- Marshall _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
