yes, it can cause confusion that the C thread local and the c++ thread_local are different animals.
But as I hope we don't want two different compiler.thread_local_storage commands, one for C and one for c++, we need to cover them both with one command. Or have two, if you like... I'll look at your PR, but no doubt you've fixed it. Renee will be pleased. K > On Nov 23, 2019, at 06:22, Marcus Calhoun-Lopez <mcalh...@macports.org> wrote: > > macOS has supported thread-local storage since Mac OS X Lion. > So __thread (GNU extension) and _Thread_local (C11) could be used. > However, the C++11 keyword was not supported until Xcode 8 [1,2]. > > There is a pull request that attempts to improve the situation [3]. > > -Marcus > > 1. > https://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports/29929949#29929949 > 2. https://developer.apple.com/videos/play/wwdc2016-405/?time=354 > 3. https://github.com/macports/macports-base/pull/161 > >> On Nov 21, 2019, at 5:10 PM, Ken Cunningham >> <ken.cunningham.web...@gmail.com> wrote: >> >> Well, I’ll be hornswaggled. >> >> Indeed it appears the compiler.thread_local_storage option in MacPorts is >> well and truly broken. It basically only works on 10.6 and less (which is >> where I often am, so I guess it always worked for me). >> >> Marcus forgot to blacklist command_line clangs < 800. >> >> We’ll have to get that fixed. >> >> <https://github.com/macports/macports-base/blob/2249c806dafa35c0bd2b2bce0bec29c94fa79856/src/port1.0/portconfigure.tcl#L768> >> >> Ken >> >> >> >>> On Nov 21, 2019, at 11:42 AM, Renee Otten <reneeot...@macports.org> wrote: >>> >>> [sorry forgot to reply to the list earlier] >>> >>> Thanks Ken, I am not sure if I can be of much help here - if you’d be >>> willing to take a look that would be great! For now I’ll just blacklist >>> clang below version 8. >>> >>> Best, >>> Renee >>> >>> >>>> On Nov 21, 2019, at 12:52 PM, Ken Cunningham >>>> <ken.cunningham.web...@gmail.com> wrote: >>>> >>>> yes, clang 800+ supported thread_local. >>>> >>>> the open-source clangs support thread_local using libc++ way back, but >>>> certainly macports-clang-5.0+. >>>> >>>> the c++11 gcc versions support it as well, using macports-installed >>>> libstdc++. >>>> >>>> All of that blacklisting logic is incorporated into Marcus' >>>> compiler.thread_local command, and the guts are in 'portconfigure.tcl'. >>>> The whole idea was to do it once there correctly, and then everyone could >>>> use that instead of figuring it out themselves. >>>> >>>> So -- if that is not being honoured in the build, something weird must be >>>> going on to make this build ignore base. >>>> >>>> That's what I'll have to help sort out, using a VM or real system running >>>> those OS versions. >>>> >>>> Ken >>>> >>>> >>>> >>>>> On 2019-11-21, at 9:35 AM, Renee Otten wrote: >>>>> >>>>> hi Ken, >>>>> >>>>> >>>>> see commits the following commits: >>>>> >>>>> https://github.com/macports/macports-ports/commit/d6e27064e928b43d412618ac7227cc016e461738 >>>>> https://github.com/macports/macports-ports/commit/c9e9e2a6263bbf9d915d9ba61877c80eed1a3089 >>>>> >>>>> in the last commit, doing compiler.blacklist-append {clang < 700} does >>>>> make it build on OS X 10.8 and 10.9, but not on 10.10 yet, because there >>>>> it uses Clang “700.1.81” >>>>> >>>>> I’d appreciate your help with it, perhaps the issue is actually different >>>>> and I don’t understand it correctly. >>>>> >>>>> Thanks again! >>>>> Renee >>> >> >