Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#57883 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: snowleopard Cc: kencu (Ken)
Port: libcxx

Description

+ 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.

Attachments (1)

main.log (45.4 KB) - added by ryandesign (Ryan Carsten Schmidt) 6 years ago.

Download all attachments as: .zip

Change History (20)

Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: main.log added

comment:1 Changed 6 years ago by 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.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:2 Changed 6 years ago by 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)

Last edited 6 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:3 Changed 6 years ago by 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...

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:4 Changed 6 years ago by kencu (Ken)

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

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by 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).

comment:7 in reply to:  5 Changed 6 years ago by 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 :>

comment:8 Changed 6 years ago by 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.

comment:9 in reply to:  3 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed

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

comment:12 in reply to:  10 Changed 6 years ago by 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.

comment:13 Changed 6 years ago by 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.

comment:14 Changed 6 years ago by 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.

Last edited 6 years ago by jmroot (Joshua Root) (previous) (diff)

comment:15 Changed 6 years ago by 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

comment:16 Changed 6 years ago by 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.

comment:17 in reply to:  13 Changed 6 years ago by 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>.

comment:18 Changed 6 years ago by 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.

comment:19 in reply to:  14 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.