llvm / clang and thread_local storage problems

[Stephen J. Butler]

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 <ryandesign at macports.org>
wrote:

>
> > 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.
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20161009/f3430d9a/attachment-0001.html>