restrict compiler for C++11 and thread-local storage

[MarcusCalhoun-Lopez]

See https://lists.macports.org/pipermail/macports-dev/2019-November/thread.html#41503

[kencu]

It looks like compiler.thread_local_storage will only function properly if the compiler.cxxstandard is set to 2011 or greater?

We'd have to add that to the guide.

Or we could unhide it from the cxxstandard block, and then it could always work.

up to you.

[jmroot]

There is no thread local storage prior to C++11. Asking for it with an earlier C++ standard can't be expected to work.

[jmroot]

The check on line 806 should probably look at ${compiler.thread_local_storage} too.

[MarcusCalhoun-Lopez]

I have added a ${compiler.thread_local_storage} check for the older Apple-provided compilers.
The change might be more for the sake of completeness since a previous check alone might be sufficient.

[jmroot]

It's possible to be using llvm-gcc-4.2 on Lion without the added check. Thanks.

[kencu]

So be sure to add to the guide then that this command only works if the cxx standard is also set.

[MarcusCalhoun-Lopez]

You point about proper documentation is well-taken.
If this pull request is accepted, I will add a few words on the Trac.

However, I would respectively suggest that this command does not only work when compiler.cxx_standard is set.
compiler.thread_local_storage yes is proper and correct if the code uses __thread or _Thread_local.

Apple even suggests that _Thread_local is to be preferred over thread_local for performance reasons.

[kencu]

for a c++ port that gets a thread_local error when building, adding

"compiler.thread_local_storage yes"

will not fix the port unless a cxxstandard is also set >= 2011.

yes, that's precise. Just imho in would be less confusing, less tickets, less time wasted, and simpler if it just blacklisted Xcode clangs <800 no matter what, because then it would always work.

But I know my "practical just-works" approach bangs heads with you guys sometimes.

[chrstphrchvz]

See #214 and https://trac.macports.org/ticket/61418: the original approach here only affected C++11 ports, but should also affect C++14 ports.