<div dir="ltr"><div dir="ltr">typo, of course. I meant<br><br><div>compiler.cxx_standard 2017<br></div>compiler.thread_local_storage yes<br><br></div><div>I'm typing this in TenFourFox right now on Tiger ;><br><br></div><div>K<br></div><div dir="ltr"><br><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Sat, Feb 13, 2021 at 3:25 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div dir="ltr"><div><div><div><div>To try to make bootstrapping clang and llvm as workable as possible, the compilers that can build them are carefully tested and the portfile tweaked to manage each one. Sometimes the compilers seem to build them, but the products don't work properly. Sometimes they don't build at all.<br><br></div>MacPorts base has some "broad strokes" compiler settings for thread_local, c++11, c++17, etc -- but these are designed to make it as easy as possible for Portfile authors to select compilers that are sure to work with their software. For example, there is an array of compilers that support varying amounts of c++17 between clang 5 and clang 9, and the matching Xcode system clangs. If we just used the "broad stroke" compiler selection in MacPorts base, we would indeed exclude a whole bunch of clang compilers that might well (and do) work to build a given version of clang. In so doing, that would make bootstrapping more complicated in many ways.<br><br></div>So, in the clang-8.0 Portfile for example we have a selection of hand-tuned blacklisting, started by Jeremy way-back-when, and then extensively tweaked by me afterwards. We (I) tried to cover every situation, but using non-default (or non-common) Xcode installs on the midrange macOS systems between 10.8 and 10.12 is really complicated. I'm usually happy to test each and every default compiler setup on those systems, and I just don't have VMs set up for non-default situations.<br><br></div>When a user comes along with a new report of a combination that doesn't work, I'm happy to tweak the blacklisting, if it is a reliable report on a well-set-up system where the Xcode matchest the CLTs and the SDK is right and the log is clear. I have done that before, and I"m happy to do that again. <br><br></div>The current blacklisting in clang-8.0 looks like this:<br>{{{<br># llvm-3.5 and later requires a C++11 runtime<br># Xcode 4.3's clang (318.x) fails per <a target="_blank" href="https://trac.macports.org/ticket/44161">https://trac.macports.org/ticket/44161</a><br># Xcode 4.5's clang (421.11.66) fails due to <a target="_blank" href="http://llvm.org/bugs/show_bug.cgi?id=20184">http://llvm.org/bugs/show_bug.cgi?id=20184</a><br># Xcode 4.6.3's clang (425.0.28) fails due to <a target="_blank" href="http://trac.macports.org/ticket/46897">http://trac.macports.org/ticket/46897</a><br># Xcode 4.6.3's clang (425.0.28) fails due to <a target="_blank" href="https://llvm.org/bugs/show_bug.cgi?id=30384">https://llvm.org/bugs/show_bug.cgi?id=30384</a><br># Xcode 5.1's clang (clang-503.0.40) has codegen issues (resulting compiler crashes)<br># Xcode 6.2's clang (600.0.57) fails due to <a target="_blank" href="https://llvm.org/bugs/show_bug.cgi?id=25753">https://llvm.org/bugs/show_bug.cgi?id=25753</a><br>compiler.blacklist *gcc* {clang < 602}<br><br># clang older than 3.5 fail due to <a target="_blank" href="https://llvm.org/bugs/show_bug.cgi?id=25753">https://llvm.org/bugs/show_bug.cgi?id=25753</a><br># new llvms build with clang-3.4 but have codegen issues resulting compiler crashes<br>compiler.blacklist-append macports-clang-3.3 macports-clang-3.4<br><br># Override the normal compiler fallback list entirely since we have<br># such specific requirements.<br>compiler.fallback   clang<br><br># 3.7 is already needed to bootstrap cmake, so is a good last resort<br># when the system clang is too old.<br>if {${os.platform} eq "darwin" && ${os.major} < 18} {<br>    compiler.fallback-append macports-clang-3.7<br>}<br><br>if {${subport} eq "lldb-${llvm_version}"} {<br>    # Xcode 6.4's clang (602.0.53) fails to build lldb with 'thread-local storage is not supported for the current target'<br>    compiler.blacklist-append {clang < 700}<br>}<br>}}}<br><br></div><div>So you can see, we are really trying to allow the maximum number of working compilers and taking aggressive steps to do so.<br><br></div><div>I could easily just say <br>{{{<br></div><div>compiler.cxx_standard 2018<br></div><div>compielr.thread_local_storage yes<br>}}}<br></div><div>and delete all that and forget about it.<br><br></div><div>I have _no idea_ what kind of wreckage that would throw into our already delicate hand-tuned compiler selection and to be honest I'm not overly interested to spend three weeks figuring that all out for each clang version, when what we have now (except for occasional user setups) has worked exceedingly well, I would think.<br><br></div><div>So work with me here, and please don't try to make this even harder than it already is by upending what amounts to many hours of work first by Jeremy and then by me to make this work properly.<br><br></div><div>Ken<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 13, 2021 at 2:35 AM Ryan Schmidt <<a target="_blank" href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Feb 13, 2021, at 03:42, Ken Cunningham wrote:<br>
<br>
> Thread local includes __thread, Thread_local, and thread_local.<br>
> <br>
> The compilers that support them are all different.<br>
> <br>
> To make it easy for people to not think about it much, especially when you’re not talking about bootstrapping compiler, etc, MacPorts base just treats them all the same.<br>
> <br>
> The system clang on 10.7 supports thread_local storage.<br>
> <br>
> But base excludes it because it doesn’t support the “thread_local” keyword.<br>
> <br>
> And 100 more complicated examples I could explain further to you if you are interested in learning more about it.<br>
<br>
Ok, so it sounds like "compiler.thread_local_storage yes" might in some circumstances exclude a compiler that would have been able to build the code. I guess when this option was added to base it was thought to be simpler to have one option that encompasses several related features.<br>
<br>
Per this thread, the clang in Xcode 7.3 doesn't have sufficient thread localness to build clang 8 on 10.11 but the clang in Xcode 8.2.1 does. That would seem to suggest that adding "compiler.thread_local_storage yes" would fix it. But a counterargument is that Xcode 7.2.1 is able to build clang 8 on 10.10. So it comes back to needing to see the build log of the failure.<br>
<br>
</blockquote></div>
</blockquote></div>