FYI, it's in the Xcode 8 release notes: https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
I did a quick test file and it seems to compile with Apple clang. No clue on compatibility issues though. On Sat, Oct 8, 2016 at 11:06 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > > On Oct 8, 2016, at 10:59 PM, Ken Cunningham < > ken.cunningham.web...@gmail.com> wrote: > > > > I've run into this again tonight. > > > > I'm using, at this moment, clang-3.7 / llvm-3.7 with macports-created > libc++ and libc++abi. > > > > > > Every once in a while, a port I'm trying to create or build will error > out due to this: > > > > error: thread-local storage is not supported for the current target > > > > /opt/local/var/macports/build/_opt_myports_devel_glbinding/ > glbinding/work/build/source/glbinding/include/glbinding/glbinding_features.h:240:36: > note: expanded from macro 'GLBINDING_THREAD_LOCAL' > > # define GLBINDING_THREAD_LOCAL __thread > > ^ > > > > In this case, I'm trying to create this port <https://github.com/ > cginternals/glbinding> which is a dev library for openGL. > > > > > > As I understand it, thread_local storage is a feature of cxx11 that > should be - but apparently isn't - supported by clang / llvm. > > > > This page <http://clang.llvm.org/cxx_status.html#n2659> says it is > enabled in clang-3.3, if your c++ runtime provides __cxa_thread_atexit, > like libc++abi 3.6 or later. > > I have libcxxabi @3.7.0_1+universal (active) platform='darwin 10' > archs='i386 x86_64' > > > > there's a thread on stackoverflow about it: > > > > <http://stackoverflow.com/questions/28094794/why-does- > apple-clang-disallow-c11-thread-local-when-official-clang-supports> > > > > which has this quote: > > > > For Xcode 7.x and earlier, here is an answer from 2014 from an Apple > engineer on the Apple Developer Forum: > > > > We don't support the thread_local implementation from the open-source > Clang because we believe we can provide a higher-performance implementation > for our platforms using various features in the dynamic linker. Such an > implementation would be ABI-incompatible with the implementation in the > open-source Clang, so we won't support thread_local until we get an > implementation we can live with for the foreseeable future. > > > > There are many smart people on this list who know a lot more about this > kind of thing than I ever will. > > > > Anyone offer any insight into this issue? > > Thanks for finding and sharing that information. It sounds like you could > get TLS by using MacPorts clang instead of Xcode clang, but that it will be > incompatible with whatever TLS implementation Apple eventually creates. > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev >
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
