gdal @3.8.0: Undefined symbols std::__1::__shared_mutex_base::lock_shared()

[nilason (Nicklas Larsson)]

GDAL fails for El Capitan (10.11), Mavericks (10.9) and Lion (10.7) with "undefined symbols" linking error:

Undefined symbols for architecture x86_64:
  "std::__1::__shared_mutex_base::lock_shared()", referenced from:
      __ZNSt3__112shared_mutex11lock_sharedB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::unlock_shared()", referenced from:
      __ZNSt3__112shared_mutex13unlock_sharedB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::lock()", referenced from:
      __ZNSt3__112shared_mutex4lockB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::unlock()", referenced from:
      __ZNSt3__112shared_mutex6unlockB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::__shared_mutex_base()", referenced from:
      __ZNSt3__112shared_mutexC2B7v160006Ev in cpl_vsi_mem.cpp.o
ld: symbol(s) not found for architecture x86_64

It is triggered by new code for GDAL 3.8.0 committed with ​dbfde65.

The call to the failing code has passed the following condition:

#if __cplusplus >= 201703L || _MSC_VER >= 1910

assuming the compiler supports the calls. But apparently the standard library doesn't contain it.

Presently, the gdal port sets the the c++ standard to 2014.

[nilason (Nicklas Larsson)]

I wonder if would be enough to set compiler.cxx_standard 2017?

[RobK88]

Great idea!

I have changed compiler.cxx_standard 2014 to compiler.cxx_standard 2017 in the Portfile for gdal and am building now on Lion. I will let you know what happens. Crossing my fingers.

[kencu (Ken)]

there is no log to refer to here in this ticket yet, but llvm/clang/libc++ tend to be pretty strict about what symbols they expose, depending on the standard that is being set by the build.

look for arguments like -std=c++17 to see what the build is actually setting.

If you see no such argument, then you get whatever the compiler decides will be it's default standard. The thing with that is that different compilers, and different versions of the same compiler, set this differently so there is no guessing what that default standard will be, usually.

[nilason (Nicklas Larsson)]

Added log from bot build.

[RobK88]

Nope. The build still fails on Lion with the same error when specifying compiler.cxx_standard 2017 in the Portfile:

Undefined symbols for architecture x86_64:
  "std::__1::__shared_mutex_base::lock_shared()", referenced from:
      __ZNSt3__112shared_mutex11lock_sharedB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::unlock_shared()", referenced from:
      __ZNSt3__112shared_mutex13unlock_sharedB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::lock()", referenced from:
      __ZNSt3__112shared_mutex4lockB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::unlock()", referenced from:
      __ZNSt3__112shared_mutex6unlockB7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::__shared_mutex_base()", referenced from:
      __ZNSt3__112shared_mutexC2B7v160006Ev in cpl_vsi_mem.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[RobK88]

main.log from Lion

[nilason (Nicklas Larsson)]

Replying to RobK88:

Nope. The build still fails on Lion with the same error when specifying compiler.cxx_standard 2017 in the Portfile:

Too bad. Would you mind share main.log file?

[nilason (Nicklas Larsson)]

Just to make sure RobK88, you did leave the line cmake.set_cxx_standard yes untouched?

The bot log contains -std=gnu++14, but your log does not set c++ standard at all.

[RobK88]

Yes. I kept the line cmake.set_cxx_standard yes. I will attach my Portfile.

[RobK88]

Portfile used with Lion build

[nilason (Nicklas Larsson)]

You can perhaps try adding configure.cxxflags-append -std=c++17

[RobK88]

I will try that and will let you know.

[RobK88]

Still no luck... But I get a different error. I will attach main.log

[ 92%] Built target gcore
/usr/bin/make  -f CMakeFiles/GDAL.dir/build.make CMakeFiles/GDAL.dir/depend
make[2]: Entering directory `/opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build'
cd /opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build && /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" /opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/gdal-3.8.0 /opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/gdal-3.8.0 /opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build /opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build /opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build/CMakeFiles/GDAL.dir/DependInfo.cmake --color=
make[2]: Leaving directory `/opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build'
/usr/bin/make  -f CMakeFiles/GDAL.dir/build.make CMakeFiles/GDAL.dir/build
make[2]: Entering directory `/opt/local/var/macports/build/_Users_rob_Development_MacPorts_local-repo_gis_gdal/gdal/work/build'
[ 92%] Linking CXX shared library libgdal.dylib
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/GDAL.dir/link.txt --verbose=ON
/opt/local/bin/clang++-mp-16 -pipe -Os -std=c++17 -DNDEBUG -I/opt/local/include -I/opt/local/include/LegacySupport -stdlib=libc++ -fno-finite-math-only -fvisibility=hidden -arch x86_64 -mmacosx-version-min=10.7 -dynamiclib -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -lMacportsLegacySupport -stdlib=libc++ -compatibility_version 34.0.0 -current_version 34.3.8 -o libgdal.34.3.8.0.dylib -install_name @rpath/libgdal.34.dylib @CMakeFiles/GDAL.dir/objects1.rsp  -Wl,-rpath,/opt/local/lib -lm /opt/local/lib/libz.dylib /opt/local/lib/libz.dylib /opt/local/lib/libcurl.dylib /opt/local/lib/libxml2.dylib /opt/local/libexec/openssl3/lib/libcrypto.dylib /opt/local/libexec/openssl3/lib/libssl.dylib /opt/local/lib/libzstd.dylib /opt/local/lib/libdeflate.dylib /opt/local/lib/liblz4.dylib /opt/local/lib/libblosc.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libz.dylib /opt/local/lib/libdeflate.dylib /opt/local/lib/libzstd.dylib /opt/local/lib/libwebp.dylib /opt/local/lib/libLerc.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/libqhull_r.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/libz.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libz.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/libjxl.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng.dylib /opt/local/lib/libz.dylib /opt/local/lib/libLerc.dylib /opt/local/lib/libzstd.dylib /opt/local/lib/libbrunslienc-c.dylib /opt/local/lib/libbrunslidec-c.dylib /opt/local/lib/libpng.dylib /opt/local/lib/libz.dylib /opt/local/lib/libaec/lib/libaec.dylib /opt/local/lib/libz.dylib /opt/local/lib/libgif.dylib /opt/local/lib/libblosc.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/libz.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/libpcre2-8.dylib /opt/local/lib/libspatialite.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/libsqlite3.dylib /opt/local/lib/libexpat.1.8.10.dylib /opt/local/lib/libxml2.dylib /opt/local/lib/libgeos_c.1.18.1.dylib /opt/local/lib/libcurl.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/proj9/lib/libproj.dylib /opt/local/lib/libiconv.dylib /opt/local/libexec/openssl3/lib/libcrypto.dylib -lm 
Undefined symbols for architecture x86_64:
  "std::__1::__shared_mutex_base::lock_shared()", referenced from:
      VSIMemHandle::Seek(unsigned long long, int) in cpl_vsi_mem.cpp.o
      VSIMemHandle::Read(void*, unsigned long, unsigned long) in cpl_vsi_mem.cpp.o
      VSIMemHandle::PRead(void*, unsigned long, unsigned long long) const in cpl_vsi_mem.cpp.o
      VSIMemFilesystemHandler::Open(char const*, char const*, bool, char const* const*) in cpl_vsi_mem.cpp.o
      VSIMemFilesystemHandler::Stat(char const*, stat*, int) in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::unlock_shared()", referenced from:
      __ZNSt3__111shared_lockINS_12shared_mutexEED2B7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::lock()", referenced from:
      VSIMemHandle::Write(void const*, unsigned long, unsigned long) in cpl_vsi_mem.cpp.o
      VSIMemHandle::Truncate(unsigned long long) in cpl_vsi_mem.cpp.o
      VSIMemFilesystemHandler::Open(char const*, char const*, bool, char const* const*) in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::unlock()", referenced from:
      __ZNSt3__111unique_lockINS_12shared_mutexEED2B7v160006Ev in cpl_vsi_mem.cpp.o
  "std::__1::__shared_mutex_base::__shared_mutex_base()", referenced from:
      VSIMemFile::VSIMemFile() in cpl_vsi_mem.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[RobK88]

main.log from Lion - Attempt #2

[nilason (Nicklas Larsson)]

patch

[nilason (Nicklas Larsson)]

Please try the attached patch with added patchfiles patch-have_shared_mutex.diff to the portfile.

It attempts to replace #if __cplusplus >= 201703L || _MSC_VER >= 1910 with configuration build test.

[RobK88]

Thanks for the patch. I am building now and will get back to you.

[RobK88]

Success!! Your patch worked.

Please note that I reverted back to compiler.cxx_standard 2014 and removed configure.cxxflags-append -std=c++17 in the Portfile.

I will attached my Portfile.

bash-3.2$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.7.5
BuildVersion:	11G63

bash-3.2$ port installed gdal
The following ports are currently installed:
  gdal @3.7.3_0+postgresql15+proj9
  gdal @3.8.0_1+postgresql15+proj9 (active)

[RobK88]

Portfile working on Lion

[RobK88]

P.S. I bumped the revision number in my Portfile. I suspect that is not needed or recommended here. See ​https://guide.macports.org/chunked/reference.html

[RobK88]

@nilason - Have you seen this PR -- ​https://github.com/macports/macports-ports/pull/21457/files ??

Looks like another to to fix the problem but I have not tested it on Lion.

[nilason (Nicklas Larsson)]

Replying to RobK88:

@nilason - Have you seen this PR -- ​https://github.com/macports/macports-ports/pull/21457/files ??

Looks like another to to fix the problem but I have not tested it on Lion.

No, that's another issue: ​https://trac.macports.org/ticket/68734.

By the way, glad it worked out!

[nilason (Nicklas Larsson)]

Replying to RobK88:

P.S. I bumped the revision number in my Portfile. I suspect that is not needed or recommended here. See ​https://guide.macports.org/chunked/reference.html

If you build locally, you don’t need to increase revision.

[nilason (Nicklas Larsson)]

Could it be that 10.7-10.11 support C++17, but are missing in some features (shared mutex)? If that is the case the patch I attached could be added to the port and also submitted upstream.

[nilason (Nicklas Larsson)]

PR ​https://github.com/macports/macports-ports/pull/21490 attempts to fix this.

[nilason (Nicklas Larsson)]

@RobK88 Could you please test the PR, the patch is slightly modified (now being in the shape that has been committed upstream).

[nilason (Nicklas Larsson)]

In 6588eacf5d17c480d2aeaf12bd29113ecba1f2ae/macports-ports (master):

gdal: fix build failure on missing std::shared_mutex

Closes #68716