On Wed, 2019-08-21 at 09:01 -0700, Marshall Clow wrote: > 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>. > >
It doesn't matter what the change was, because the error is in firefox. It violates the c++ convention that you NEVER put 'using namespace' statements in a header file. Never. Because, this stuff happens if you do. -- Ian _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"