llvm / clang and thread_local storage problems

Ryan Schmidt ryandesign at macports.org
Sat Oct 8 21:06:21 PDT 2016


> On Oct 8, 2016, at 10:59 PM, Ken Cunningham <ken.cunningham.webuse at 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.



More information about the macports-dev mailing list