OK wow that's quite the analysis! I'm going to go with just incorporating the c++11 1.1 PG ... it'll work for now, and once "we" get around to dealing with the changes to base from PR #88, it'll be a "universal" change to all Portfiles that use c++11 PGs ... so we'd be good to go! Thanks! - MLD
On Wed, Feb 13, 2019, at 1:23 PM, Ken Cunningham wrote: > __thread came first, then thread_local a bit later. > > the difference is that thread_local allows more complicated initializers > and destructors ("non-trivial"). It is c++11, as you said. > > > quite old gcc versions support __thread I think the earliest one was > gcc 4.1 > <https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Thread_002dLocal.html> > > gcc 4.8+ supports thread_local > <https://www.gnu.org/software/gcc/gcc-4.8/changes.html> > > > For Open Source clang, we have this reference > <https://clang.llvm.org/cxx_status.html> that shows clang-3.3+ supported > it with a proper runtime. That runtime exists on 10.7+. As you know, I > have recently enabled "emulated thread_local" on clang-5.0+ (to match up > with the c++11 PG) for both stdlib=libc++ and stdlib=macports-libstdc++ > (our c++11 runtimes). I wasn't planning on porting that back any > further. > > > For Xcode clang, you already have that -- 900+. Apple introduced a > better-performance thread_local system that (as I understand it) > involved integration into dyld . > > > > So gcc-4.8+ and clang-5.0+ is reliable on all systems using a c++11 > runtime, although there are some systems that can use thread_local with > clang-3.4 to clang-4.0 it appears (untested by me). > > My idea was to make the cxx11 PG more or less == thread_local capability. > > This has _all_ been changed in base recently by Marcus' base PR #88, so > it's a moving target. > > Ken >