libcxx @5.0.1_3: error: thread-local storage is unsupported for the current target

[ryandesign (Ryan Carsten Schmidt)]

+ for FILE in '../src/*.cpp'
+ /opt/local/bin/clang++-mp-3.4 -c -g -O3 -arch x86_64 -arch i386 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libcxx/libcxx/work/libcxxabi-5.0.1.src/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libcxx/libcxx/work/libcxx-5.0.1.src/include -Os -std=c++11 -stdlib=libc++ -nostdinc++ -fstrict-aliasing -Wstrict-aliasing=2 -Wsign-conversion -Wshadow -Wconversion -Wunused-variable -Wmissing-field-initializers -Wchar-subscripts -Wmismatched-tags -Wmissing-braces -Wshorten-64-to-32 -Wsign-compare -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter -Wnewline-eof -D_LIBCPP_BUILDING_LIBRARY -I../include ../src/cxa_thread_atexit.cpp
../src/cxa_thread_atexit.cpp:65:3: error: thread-local storage is unsupported for the current target
  __thread DtorList* dtors = nullptr;
  ^
../src/cxa_thread_atexit.cpp:67:3: error: thread-local storage is unsupported for the current target
  __thread bool dtors_alive = false;
  ^
2 errors generated.

[kencu (Ken)]

That is supposed to build with clang-5.0, and only if clang-5.0 is installed. Otherwise it is supposed to build the non-emulated-tls version using any clang compiler.

Now to see why that is not happening...

I see it tried to build with clang-3.4 instead.

[ryandesign (Ryan Carsten Schmidt)]

Ok, on buildbot, it built the non-emulated-tls version, because clang-5.0 is not installed.

On my machine, I already had clang-5.0 @5.0.2_2 installed, so it tried to build the emulated-tls version.

Nowhere does the Portfile say that it should use clang-5.0 when using the emulated_tls variant.

The port does blacklist any already-installed versions of clang 3.5+. (clang 3.5 and newer are conditionally blacklisted to prevent dependency cycles)

[kencu (Ken)]

OK. In this part:

    if {${os.major} < 11} {
        variant emulated_tls description {build libcxxabi and libcxx with support for emulated thread_local storage} {}
    }
    # only selected clang versions support emulated-tls
    foreach ver {5.0} {
        if {[file exists ${prefix}/bin/clang-mp-${ver}] && ${os.major} < 11} {
            default_variants-append +emulated_tls
        }
    }

if I whitelist the installed working compilers like this:

    if {${os.major} < 11} {
        variant emulated_tls description {build libcxxabi and libcxx with support for emulated thread_local storage} {}
    }
    # only selected clang versions support emulated-tls
    foreach ver {5.0} {
        if {[file exists ${prefix}/bin/clang-mp-${ver}] && ${os.major} < 11} {
            default_variants-append +emulated_tls
            compiler.whitelist-append macports-clang-${ver}
        }
    }

that should do what I'm after...

[kencu (Ken)]

and we can add several more to the ver now, because I've since fixed 6.0 and 7.0 as well.

[ryandesign (Ryan Carsten Schmidt)]

But you can't use clang 3.5 or later to build libcxx, because clang 3.5 and later depend on libcxx. Dependency cycle. Why they were blacklisted.

[kencu (Ken)]

I'm not 100% sure how we might get the emulated-tls version of libcxx on the buildbot, though. There appears to be an insurmountable manual step involved.

Although I also have libcxx building WITH emulated-tls built by gcc6, gcc7, and gcc8 that might be another way around that, if Jeremy accepts that method (which is not a given).

[kencu (Ken)]

Replying to ryandesign:

But you can't use clang 3.5 or later to build libcxx, because clang 3.5 and later depend on libcxx. Dependency cycle. Why they were blacklisted.

Once you have libcxx installed by clang-3.4, you can build and use clang-5.0, and then use clang-5.0 to build a new version of libcxx that has emulated-tls support.

Bootstrapping is a fun puzzle :>

[ryandesign (Ryan Carsten Schmidt)]

Which would mean that anything that needs emulated tls support on Snow Leopard needs manual intervention to build, and therefore wouldn't be buildable on the buildbot. It would be better if that were not the case.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

if I whitelist the installed working compilers like this:

    if {${os.major} < 11} {
        variant emulated_tls description {build libcxxabi and libcxx with support for emulated thread_local storage} {}
    }
    # only selected clang versions support emulated-tls
    foreach ver {5.0} {
        if {[file exists ${prefix}/bin/clang-mp-${ver}] && ${os.major} < 11} {
            default_variants-append +emulated_tls
            compiler.whitelist-append macports-clang-${ver}
        }
    }

that should do what I'm after...

I've now tried making this change.

I have the following outdated ports:

$ port outdated libcxx clang-5.0
The following installed ports are outdated:
clang-5.0                      5.0.2_2 < 5.0.2_3         
libcxx                         5.0.1_2 < 5.0.1_3        

If I try to upgrade clang-5.0, MacPorts tries to upgrade its dependency libcxx first, which tries to build with clang-5.0 @5.0.2_2, which fails:

$ sudo port upgrade clang-5.0
--->  Computing dependencies for libcxx
--->  Fetching archive for libcxx
--->  Attempting to fetch libcxx-5.0.1_3+emulated_tls+universal.darwin_10.i386-x86_64.tbz2 from https://packages.macports.org/libcxx
--->  Attempting to fetch libcxx-5.0.1_3+emulated_tls+universal.darwin_10.i386-x86_64.tbz2 from http://nue.de.packages.macports.org/libcxx
--->  Attempting to fetch libcxx-5.0.1_3+emulated_tls+universal.darwin_10.i386-x86_64.tbz2 from http://sea.us.packages.macports.org/macports/packages/libcxx
--->  Fetching distfiles for libcxx
--->  Verifying checksums for libcxx
--->  Extracting libcxx
--->  Applying patches to libcxx
--->  Configuring libcxx
--->  Building libcxx
Error: Failed to build libcxx: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libcxx/libcxx/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

+ for FILE in '../src/*.cpp'
+ /opt/local/bin/clang++-mp-5.0 -c -g -O3 -arch x86_64 -arch i386 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libcxx/libcxx/work/libcxxabi-5.0.1.src/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libcxx/libcxx/work/libcxx-5.0.1.src/include -Os -std=c++11 -stdlib=libc++ -nostdinc++ -fstrict-aliasing -Wstrict-aliasing=2 -Wsign-conversion -Wshadow -Wconversion -Wunused-variable -Wmissing-field-initializers -Wchar-subscripts -Wmismatched-tags -Wmissing-braces -Wshorten-64-to-32 -Wsign-compare -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter -Wnewline-eof -D_LIBCPP_BUILDING_LIBRARY -I../include ../src/cxa_thread_atexit.cpp
../src/cxa_thread_atexit.cpp:65:3: error: thread-local storage is not supported for the current target
  __thread DtorList* dtors = nullptr;
  ^
../src/cxa_thread_atexit.cpp:67:3: error: thread-local storage is not supported for the current target
  __thread bool dtors_alive = false;
  ^
2 errors generated.

But if I try to upgrade libcxx first, MacPorts tries to upgrade its dependency clang-5.0 first, which succeeds, and then libcxx can build because it's building with clang-5.0 @5.0.2_3:

$ sudo port clean libcxx
--->  Cleaning libcxx
$ sudo port upgrade libcxx
--->  Computing dependencies for clang-5.0
--->  Fetching archive for clang-5.0
--->  Attempting to fetch clang-5.0-5.0.2_3+analyzer+emulated_tls+libstdcxx.darwin_10.x86_64.tbz2 from https://packages.macports.org/clang-5.0
--->  Attempting to fetch clang-5.0-5.0.2_3+analyzer+emulated_tls+libstdcxx.darwin_10.x86_64.tbz2.rmd160 from https://packages.macports.org/clang-5.0
--->  Installing clang-5.0 @5.0.2_3+analyzer+emulated_tls+libstdcxx
--->  Cleaning clang-5.0
--->  Computing dependencies for clang-5.0
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
--->  Deactivating clang-5.0 @5.0.2_2+analyzer+libstdcxx
--->  Cleaning clang-5.0
--->  Activating clang-5.0 @5.0.2_3+analyzer+emulated_tls+libstdcxx
--->  Cleaning clang-5.0
--->  Computing dependencies for libcxx
--->  Fetching archive for libcxx
--->  Attempting to fetch libcxx-5.0.1_3+emulated_tls+universal.darwin_10.i386-x86_64.tbz2 from https://packages.macports.org/libcxx
--->  Attempting to fetch libcxx-5.0.1_3+emulated_tls+universal.darwin_10.i386-x86_64.tbz2 from http://nue.de.packages.macports.org/libcxx
--->  Attempting to fetch libcxx-5.0.1_3+emulated_tls+universal.darwin_10.i386-x86_64.tbz2 from http://sea.us.packages.macports.org/macports/packages/libcxx
--->  Fetching distfiles for libcxx
--->  Verifying checksums for libcxx
--->  Extracting libcxx
--->  Applying patches to libcxx
--->  Configuring libcxx
--->  Building libcxx
--->  Staging libcxx into destroot
--->  Installing libcxx @5.0.1_3+emulated_tls+universal
--->  Cleaning libcxx
--->  Deactivating libcxx @5.0.1_2+universal
--->  Cleaning libcxx
--->  Activating libcxx @5.0.1_3+emulated_tls+universal
--->  Cleaning libcxx

This kind of unexpected behavior is what happens with circular dependencies, which is why we want to avoid them.

And as I said elsewhere, I'm not using LibcxxOnOlderSystems, so I think this problem will affect all users upgrading ports on 10.6.

[kencu (Ken)]

The way I pushed this through was

1. updated clang-5.0 to the TLS-supporting version and revbumped
2. waited three weeks until that flowed through
3. updated libcxx to the TLS supporting version

I guess you found a wrinkle there for someone who has an old clang-5.0 installed, who hasn't updated for a while, and then like you gets both the libcxx update and clang-5.0 update request at the same time.

Funny enough you'd have been fine if you had no clang-5.0 installed -- then you'd have got the new updated clang-5.0 one right off the buildbot, and all would be well.

Now let me ponder a way to automate the case of someone with an old clang-5.0, who hasn't updated in a while, now getting both the libcxx and the clang-5.0 updates at the same time ...

I don't think this is everyone with 10.6. Only a wedge case.

[kencu (Ken)]

In c6b1b394d4f75408afb7653f73b5a46bff1d9bba/macports-ports (master):

libcxx: force emulated_tls variant to build with a compatible clang

only the whitelisted clang versions are capable of building this variant
and only if they have emulated_tls enabled

covers the case where a user has an older clang-5.0 version installed
or does not have the emulated_tls variant enabled on clang

closes: #57883

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

I don't think this is everyone with 10.6. Only a wedge case.

Ok, everyone who had clang-5.0 and libcxx installed, and who didn't update during that three-week period.

[ryandesign (Ryan Carsten Schmidt)]

Is there any way to backport the changes you made to clang-5.0 to support emulated tls to clang-3.4, which doesn't require libcxx? If so, then libcxx could continue to build with clang-3.4 which would break the dependency cycle.

[jmroot (Joshua Root)]

We need to figure this stuff out if we're ever going to be able to make libcxx the default on 10.6. My suggestion would be bootstrap subports for the bits that need to be built twice in different ways. E.g. initially install libcxx-bootstrap which builds with clang-3.4, which together can be used to build clang-5.0-bootstrap which can be used to build libcxx.

[kencu (Ken)]

As I see it, there is no more dependency cycle. The case Ryan came across that I handn't anticipated has been covered now. Can't think of any others, but we'll see.

Changing to libc++ on 10.6.8 and earlier will always need manual steps. Once we change to that, we'll all be much happier, and that is the only setup we should support.

K

[jmroot (Joshua Root)]

Changing to libc++ on 10.6 does not need to require manual steps, and shouldn't. Once everything is ready, we should be able to simply release a new base version that changes the default cxx_stdlib and rev-upgrade will take care of the rest.

[kencu (Ken)]

Replying to ryandesign:

Is there any way to backport the changes you made to clang-5.0 to support emulated tls to clang-3.4, which doesn't require libcxx? If so, then libcxx could continue to build with clang-3.4 which would break the dependency cycle.

I don't think it can be backported that far. The functionality came into llvm/clang here <​https://reviews.llvm.org/D10524>, and appears to have first become available as of clang/llvm-3.8 <​http://releases.llvm.org/3.8.0/docs/ReleaseNotes.html>.

[kencu (Ken)]

What I do have to offer to the Impossible Mission Force, should they decide to accept it, is a version of libcxx that can be built from bare metal with full emulated-TLS support using gcc5, 6, and 7 on Intel and PPC, and on Intel, gcc8.

Actually might not be a terrible bootstrapping plan, as it builds nostdinc++ and nostdlibs, so it is just using gcc as a c++11 compiler while using the libc++ headers, and it has no other dependencies later on.

And then you can build clang-3.4 against libstdc++ as we do now, and use use clang-3.4 to build clang-5.0 against libc++, and then you're in business. We should then build pretty much everything with clang-5.0 or newer after that, which is very similar to a current macOS system, I find.

There, however, a bunch of other toolchain upgrade steps for cctools and ld64 in the LibcxxOnOlderSystems instructions that remain as bootstrap issues. clang-3.4 can probably build most or all of them, though.

[kencu (Ken)]

Replying to jmroot:

E.g. initially install libcxx-bootstrap which builds with clang-3.4, which together can be used to build clang-5.0-bootstrap which can be used to build libcxx.

clang-5.0 builds the same whether libcxx supports emulated-tls or not, so there wouldn't be a clang-5.0-bootstrap needed.

One less worry.