On 2020-12-01 10:01 a.m., Ryan Schmidt wrote:
apple-gcc42's +bootstrap variant is not suitable for the buildbot either
because of that manual step.
Just so I understand the equipment -- is the buildbot system at all
manually controllable?
ie is it even technically possible to do this o
On Tue, 1 Dec 2020, Ryan Schmidt wrote:
On Dec 1, 2020, at 00:07, Ken Cunningham wrote:
another reasonably simple option would be to have a manual step, and
copy what happens with apple-gcc42 +bootstrap.
We make up a non-TLS variant of libcxx, call it libcxx +bootstrap, and
default to inst
On Dec 1, 2020, at 00:07, Ken Cunningham wrote:
> another reasonably simple option would be to have a manual step, and copy
> what happens with apple-gcc42 +bootstrap.
>
>
> We make up a non-TLS variant of libcxx, call it libcxx +bootstrap, and
> default to installing that if there is nothi
another reasonably simple option would be to have a manual step, and copy what
happens with apple-gcc42 +bootstrap.
We make up a non-TLS variant of libcxx, call it libcxx +bootstrap, and default
to installing that if there is nothing in /usr/lib/libc++.dylib.
Then the port notes (like apple-gc
So — figuring out how to bootstrap libcxx to the +emulated_tls variant (which
we increasingly need) is a real PITA.
I might sort it out — building another libcxx in some tucked-away location,
with a bunch of stuff needed to get to clang-5.0 linked against that one, and
using that to build the r
