cgal5 @5.0.2: error: thread-local storage is not supported for the current target

[ryandesign (Ryan Carsten Schmidt)]

​cgal5 doesn't build on Yosemite:

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_gis_cgal5/cgal5/work/CGAL-5.0.2/include/CGAL/Modular_arithmetic/Residue_type.h:68:5: error: thread-local storage is not supported for the current target
    CGAL_STATIC_THREAD_LOCAL_VARIABLE(int, prime_int, 67111067);
    ^
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_gis_cgal5/cgal5/work/CGAL-5.0.2/include/CGAL/tss.h:21:10: note: expanded from macro 'CGAL_STATIC_THREAD_LOCAL_VARIABLE'
  static thread_local TYPE VAR(ARG1)
         ^

Maybe this can be made to work using:

compiler.thread_local_storage yes
# Work around thread local compiler selection bug. Remove after
# https://github.com/macports/macports-base/pull/161 is released.
PortGroup compiler_blacklist_versions 1.0
compiler.blacklist-append {clang < 800}

[ryandesign (Ryan Carsten Schmidt)]

Actually ​https://github.com/macports/macports-base/pull/161 is only about ports that use thread local storage and also C++11. cgal5 doesn't specify C++11 so let me just try setting the configure.thread_local_storage option.

[ryandesign (Ryan Carsten Schmidt)]

In a5b8a863c5ce17544d02f6b5b0bc017402946674/macports-ports (master):

cgal5: Set compiler.thread_local_storage yes

See: #60638

[ryandesign (Ryan Carsten Schmidt)]

That still fails. Looking at the build log, I see -std=gnu++14. So the port should be indicating that requirement, and we do need the added blacklist after all.

[ryandesign (Ryan Carsten Schmidt)]

In 48acd733c00f3ad5d0e24b810d2e54ad750b7695/macports-ports (master):

cgal5: Require C++14

Closes: #60638

[kencu (Ken)]

thread_local always implies std=c++11 or greater. <​https://en.cppreference.com/w/cpp/keyword/thread_local>

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

thread_local always implies std=c++11 or greater. <​https://en.cppreference.com/w/cpp/keyword/thread_local>

In ​https://github.com/macports/macports-base/pull/161/files it says:

# macOS has supported thread-local storage since Mac OS X Lion.
# So __thread (GNU extension) and _Thread_local (C11) could be used.
# However, the C++11 keyword was not supported until Xcode 8

I took this to mean that MacPorts base 2.6.2's compiler.thread_local_storage yes works for projects that don't use the C++11 keyword, but doesn't work for projects that do use the C++11 keyword. Since this port didn't indicate that it used C++11, I began by presuming that it did not. That seemed to be contradicted by the results from the buildbot after making this change which is why I added the second change, which resulted in successful builds.

don't forget that many build systems will test for certain standards and use them if available. Just because the build line indicated -std=gnu++14 on this particular system, it does not necessarily mean that the software actually requires that. Just that it used that during this build.

Well you're right about that. Checking the 10.9 build log, I see it used -std=gnu++1y instead. So I'll reduce the cxx_standard to 2011.

Not a big deal -- it will probably just mean that ports that might have built with an older compiler will be forced to build with a newer one, but I know you don't like that.

You're right, I don't like requiring a newer compiler when that's not necessary. In this case, however, it is necessary, due to the thread local storage requirement. C++11 requires clang 500; C++14 requires clang 602; thread local storage requires clang 800.

[ryandesign (Ryan Carsten Schmidt)]

In 70b3229ff51ffd0a63349583e331108f2e83563d/macports-ports (master):

cgal5: Reduce C++ standard to 2011

See: #60638