Building Clang 8/9 in El Capitan

[Ken Cunningham]

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.webuse at 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 <ryandesign at 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.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210213/b5f996b1/attachment.htm>