Building Clang 8/9 in El Capitan

[Ken Cunningham]

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/db863c44/attachment.htm>