Opened 13 months ago

Last modified 10 months ago

#66953 assigned defect

cmake @3.24.3: Does not compile with SDK 10.12

Reported by: lukaso (Lukas Oberhuber) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: mascguy (Christopher Nielsen)
Port: cmake

Description

This port has stopped successfully compiling on x86_64 with 10.12 SDK. Here is the failure output.

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.24.3/Tests/CMakeLib && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.24.3/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CMakeLibTests.dir/link.txt --verbose=ON
/Library/Developer/CommandLineTools/usr/bin/clang++ -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk -arch x86_64 -O3 -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk -arch x86_64 CMakeFiles/CMakeLibTests.dir/CMakeLibTests.cxx.o CMakeFiles/CMakeLibTests.dir/testArgumentParser.cxx.o CMakeFiles/CMakeLibTests.dir/testCTestBinPacker.cxx.o CMakeFiles/CMakeLibTests.dir/testCTestResourceAllocator.cxx.o CMakeFiles/CMakeLibTests.dir/testCTestResourceSpec.cxx.o CMakeFiles/CMakeLibTests.dir/testCTestResourceGroups.cxx.o CMakeFiles/CMakeLibTests.dir/testGccDepfileReader.cxx.o CMakeFiles/CMakeLibTests.dir/testGeneratedFileStream.cxx.o CMakeFiles/CMakeLibTests.dir/testJSONHelpers.cxx.o CMakeFiles/CMakeLibTests.dir/testRST.cxx.o CMakeFiles/CMakeLibTests.dir/testRange.cxx.o CMakeFiles/CMakeLibTests.dir/testOptional.cxx.o CMakeFiles/CMakeLibTests.dir/testString.cxx.o CMakeFiles/CMakeLibTests.dir/testStringAlgorithms.cxx.o CMakeFiles/CMakeLibTests.dir/testSystemTools.cxx.o CMakeFiles/CMakeLibTests.dir/testUTF8.cxx.o CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o CMakeFiles/CMakeLibTests.dir/testXMLSafe.cxx.o CMakeFiles/CMakeLibTests.dir/testFindPackageCommand.cxx.o CMakeFiles/CMakeLibTests.dir/testUVProcessChain.cxx.o CMakeFiles/CMakeLibTests.dir/testUVRAII.cxx.o CMakeFiles/CMakeLibTests.dir/testUVStreambuf.cxx.o CMakeFiles/CMakeLibTests.dir/testCMExtMemory.cxx.o CMakeFiles/CMakeLibTests.dir/testCMExtAlgorithm.cxx.o CMakeFiles/CMakeLibTests.dir/testCMExtEnumSet.cxx.o CMakeFiles/CMakeLibTests.dir/testCMFilesystemPath.cxx.o -o CMakeLibTests  ../../Source/libCMakeLib.a ../../Source/libCTestLib.a ../../Source/libCMakeLib.a ../../Source/kwsys/libcmsys.a ../../Utilities/std/libcmstd.a /opt/local/lib/libexpat.dylib /opt/local/lib/libz.dylib /opt/local/lib/libarchive.dylib ../../Utilities/cmjsoncpp/libcmjsoncpp.a /opt/local/lib/libuv.dylib ../../Utilities/cmlibrhash/libcmlibrhash.a -framework CoreFoundation -framework CoreServices /opt/local/lib/libcurl.dylib 
Undefined symbols for architecture x86_64:
  "std::bad_optional_access::~bad_optional_access()", referenced from:
      std::__1::__throw_bad_optional_access() in testOptional.cxx.o
  "typeinfo for std::bad_optional_access", referenced from:
      std::__1::__throw_bad_optional_access() in testOptional.cxx.o
      GCC_except_table21 in testOptional.cxx.o
  "vtable for std::bad_optional_access", referenced from:
      std::__1::__throw_bad_optional_access() in testOptional.cxx.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Attachments (2)

cmake.log (1.4 MB) - added by lukaso (Lukas Oberhuber) 13 months ago.
main.log (1.9 MB) - added by lukaso (Lukas Oberhuber) 10 months ago.

Change History (12)

comment:1 Changed 13 months ago by jmroot (Joshua Root)

Owner: set to michaelld
Status: newassigned

comment:2 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)

Are you using the 10.12 SDK on macOS 10.12 or on a different macOS version?

We have successful builds of this port on all OS versions on our automated buildbot system.

comment:3 Changed 13 months ago by lukaso (Lukas Oberhuber)

I believe this is the cause of the problem, which has now hit cmake: https://stackoverflow.com/questions/44217316/how-do-i-use-stdoptional-in-c

comment:4 Changed 13 months ago by lukaso (Lukas Oberhuber)

I'm building on Big Sur and Ventura and setting the SDK to 10.12 and the minimum os version. I don't have access to CI that can actually run 10.12.

comment:5 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)

Ok. Cross-OS-version compilation is prone to problems like this. However, it sounds like this is supposed to work (or at least was supposed to work 3 years ago), so it may be a simple bug that can be fixed.

The cmake port requires a C++14 compiler but will use features from C++17 (like "optional") if they are detected to work. It sounds like maybe something has gone wrong with the detection, and it has perhaps determined that "optional" is available on the basis of your Big Sur / Ventura libc++ when it needs to be looking at the Sierra libc++ in the 10.12 SDK that doesn't support it.

Please attach the main.log file. I'm expecting to see a line like:

:info:configure -- Checking if compiler supports needed C++17 constructs - yes

I have not checked but I assume that what the line should say, when compiling for 10.12, is:

:info:configure -- Checking if compiler supports needed C++17 constructs - no

MacPorts contains a patch to that detection which was intended to improve it, but maybe it doesn't work correctly or maybe it recently broke. The patch was added 4 years ago. I don't know why we have this patch in MacPorts rather than submitting it to the developers of cmake. You could try removing the patch to see if that changes anything; maybe in the intervening years upstream fixed the problem a different way that interferes with our patch.

Last edited 13 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:6 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)

Attaching the file $(port work cmake)/*/CMakeFiles/CMakeOutput.log may also help since that tells us what flags were used when checking for "optional" support (where it says "Determining if compiler supports needed C++17 constructs passed with the following output").

Changed 13 months ago by lukaso (Lukas Oberhuber)

Attachment: cmake.log added

comment:7 Changed 13 months ago by lukaso (Lukas Oberhuber)

You are absolutely right about the C++17 constructs - yes. I unfortunately can't access the CMakeOutput.log. It's including the right SDK so that doesn't seem to be the problem.

comment:8 Changed 10 months ago by lukaso (Lukas Oberhuber)

I worked around this problem by using precompiled cmake, but I'm switching to non-sudo build where that is no longer possible.

Attaching my recent build file.

Changed 10 months ago by lukaso (Lukas Oberhuber)

Attachment: main.log added

comment:9 Changed 10 months ago by lukaso (Lukas Oberhuber)

Do you think this is happening because the tests are not respecting MACOS_DEPLOYMENT_TARGET and/or SDKROOT but then using them to compile?

comment:10 Changed 10 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added
Note: See TracTickets for help on using tickets.