typo, of course. I meant compiler.cxx_standard 2017 compiler.thread_local_storage yes
I'm typing this in TenFourFox right now on Tiger ;> K On Sat, Feb 13, 2021 at 3:25 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > 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. > > 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. > > 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. > > 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. > > The current blacklisting in clang-8.0 looks like this: > {{{ > # llvm-3.5 and later requires a C++11 runtime > # Xcode 4.3's clang (318.x) fails per > https://trac.macports.org/ticket/44161 > # Xcode 4.5's clang (421.11.66) fails due to > http://llvm.org/bugs/show_bug.cgi?id=20184 > # Xcode 4.6.3's clang (425.0.28) fails due to > http://trac.macports.org/ticket/46897 > # Xcode 4.6.3's clang (425.0.28) fails due to > https://llvm.org/bugs/show_bug.cgi?id=30384 > # Xcode 5.1's clang (clang-503.0.40) has codegen issues (resulting > compiler crashes) > # Xcode 6.2's clang (600.0.57) fails due to > https://llvm.org/bugs/show_bug.cgi?id=25753 > compiler.blacklist *gcc* {clang < 602} > > # clang older than 3.5 fail due to > https://llvm.org/bugs/show_bug.cgi?id=25753 > # new llvms build with clang-3.4 but have codegen issues resulting > compiler crashes > compiler.blacklist-append macports-clang-3.3 macports-clang-3.4 > > # Override the normal compiler fallback list entirely since we have > # such specific requirements. > compiler.fallback clang > > # 3.7 is already needed to bootstrap cmake, so is a good last resort > # when the system clang is too old. > if {${os.platform} eq "darwin" && ${os.major} < 18} { > compiler.fallback-append macports-clang-3.7 > } > > if {${subport} eq "lldb-${llvm_version}"} { > # Xcode 6.4's clang (602.0.53) fails to build lldb with 'thread-local > storage is not supported for the current target' > compiler.blacklist-append {clang < 700} > } > }}} > > So you can see, we are really trying to allow the maximum number of > working compilers and taking aggressive steps to do so. > > I could easily just say > {{{ > compiler.cxx_standard 2018 > compielr.thread_local_storage yes > }}} > and delete all that and forget about it. > > 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. > > 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. > > Ken > > On Sat, Feb 13, 2021 at 2:35 AM Ryan Schmidt <ryandes...@macports.org> > wrote: > >> >> >> On Feb 13, 2021, at 03:42, Ken Cunningham wrote: >> >> > Thread local includes __thread, Thread_local, and thread_local. >> > >> > The compilers that support them are all different. >> > >> > 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. >> > >> > The system clang on 10.7 supports thread_local storage. >> > >> > But base excludes it because it doesn’t support the “thread_local” >> keyword. >> > >> > And 100 more complicated examples I could explain further to you if you >> are interested in learning more about it. >> >> 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. >> >> 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. >> >>