gdal @2.3.1: error: thread-local storage is not supported for the current target

[ryandesign (Ryan Carsten Schmidt)]

gdal @2.3.1 fails to build ​on OS X 10.9 with Xcode 6.2 and ​on OS X 10.10 with Xcode 7.2.1 when using Xcode's clang, with:

ersdataset.cpp:612:12: error: thread-local storage is not supported for the current target
    static thread_local int nRecLevel = 0;
           ^
ersdataset.cpp:987:16: error: thread-local storage is not supported for the current target
        static thread_local int nRecLevel = 0;
               ^
2 errors generated.

I wonder if using a newer compiler from MacPorts would fix that. Apple didn't include thread local storage in Xcode's clang until Xcode 8, but open-source clang got that feature much earlier.

It builds fine on OS X 10.11 and later using Xcode clang, and on Mac OS X 10.7 and 10.8 using MacPorts clang 5.0 (which happens because the cxx11 1.1 portgroup blacklists {clang < 500}).

I suggest adding compiler.blacklist-append {clang < 800} to the Portfile.

[kencu (Ken)]

Looks like the thread support can be turned off as well, if needed:

 ./configure --help | grep thread
  --with-threads=ARG    Include thread safe support (ARG=yes(default), no or linkopt)

[Veence (Vincent)]

Excellent finding. Ryan, what is best? Disabling thread safe if Xcode doesn’t support it, or extend its support through the use of a macports compiler?

[gnw3]

Macports should aim to honor the upstream default configuration, e.g., --with-threads=yes. Other platforms will mostly use the default, so this helps to minimize cross-platform differences. Macports provides newer compilers so it makes sense to use them where upstream uses recent compilers.

[ryandesign (Ryan Carsten Schmidt)]

I agree, and continue to recommend adding compiler.blacklist-append {clang < 800} to the Portfile.

On 10.6 and earlier, thread-local storage can't be used for other reasons, so I would disable it there.

[Veence (Vincent)]

In c201c88ec6f8aecb7bb1a4a8b638b384c2497c6e/macports-ports (master):

gdal: disable old clang compilers. Fixes #56908

[jolivetr]

I stilll have the same issue although I ran a selfupdate.
I am still on OSX 11.6 with clang-700
Any idea? Attached is the log file

[kencu (Ken)]

It's trying to build it with mpicxx-openmpi-mp, presumably becaue the +openmpi variant is set, and that apparently does not support thread_local.

:info:build /bin/sh /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/libtool --mode=compile --silent --tag=CXX /opt/local/bin/mpicxx-openmpi-mp -std=c++14 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/port -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/gcore -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/alg -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/ogr -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/ogr/ogrsf_frmts -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/gnm -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/apps -DHAVE_AVX_AT_COMPILE_TIME -DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME -pipe -DGDAL_COMPILATION -arch x86_64  -Wall -Wextra -Winit-self -Wunused-parameter -Wformat -Werror=format-security -Wno-format-nonliteral -Wshorten-64-to-32 -Wshadow -Werror=vla -Wdate-time -Wnull-dereference -Wextra-semi -Wfloat-conversion -Wdocumentation -Wno-documentation-deprecated-sync -Wunused-private-field -Wmissing-prototypes -Wmissing-declarations -Wnon-virtual-dtor -Woverloaded-virtual -fno-operator-names -Wimplicit-fallthrough  -I../raw -DGNM_ENABLED -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/port  -DGDAL_COMPILATION -I/opt/local/include -c -o ../o/ersdataset.lo ersdataset.cpp

:info:build ersdataset.cpp:612:12: error: thread-local storage is not supported for the current target
:info:build     static thread_local int nRecLevel = 0;
:info:build            ^
:info:build ersdataset.cpp:987:16: error: thread-local storage is not supported for the current target
:info:build         static thread_local int nRecLevel = 0;
:info:build                ^

[Veence (Vincent)]

Oops sorry, hadn't seen that. Is it solved with the bump to 2.3.2?

[jolivetr]

No, it is still the case. Why does it pick up this mpi version? How can I modify this?

Thanks for the help,
R

[kencu (Ken)]

Replying to jolivetr:

No, it is still the case. Why does it pick up this mpi version? How can I modify this?

Thanks for the help,
R

You apparently have the +openmpi version installed specifically. You need to find a way to install it without the openmpi variant, at least until it gets fixed. Here's how you see what you have installed:

port -v installed gdal

Presumably you will then see some version of gdal installed with the +openmpi variant specified. You could force it to be without openmpi by installing the new version with -openmpi but that is messy. Probably better to just install a clean set of variants in the first place by starting fresh with gdal.

sudo port uninstall gdal

(if port complains this will break some things, accept that and say yes). Then:

sudo port -v install gdal

and you should get a clean version, without openmpi.

[kencu (Ken)]

I should note that even if the +openmpi version is not set on those systems, we may have some troubles and need to do some clang blacklisting as you specified.

[jolivetr]

My problem is I use gdal+hdf5 and my hdf5 needs openmpi (I need it for some stuff), which forces gdal to compile with openmpi...

[kencu (Ken)]

Replying to jolivetr:

My problem is I use gdal+hdf5 and my hdf5 needs openmpi (I need it for some stuff), which forces gdal to compile with openmpi...

I think then - at this moment in time - turning off the thread support in gdal might be your best bet. Vince has a dozen variants already in gdal, so he might do that one day for you. For right now, if you wanted it built today, I would do this

bbedit `port file gdal`

find the configure.args-append section, and add this line in, to match the others:

--with-threads=no 

save the Portfile, and try your build again.

[Veence (Vincent)]

Oh, this is a good idea. Shall implement that tomorrow.