cmake @3.29.5_0: dyld: lazy symbol binding failed: Symbol not found: __ZNSo9_M_insertIeEERSoT_ on 10.5 ppc with libgcc14

[rmottola (Riccardo)]

with new gcc 14

-- Detecting C compiler ABI info
dyld: lazy symbol binding failed: Symbol not found: __ZNSo9_M_insertIeEERSoT_
  Referenced from: /opt/local/bin/cmake-orig
  Expected in: /opt/local/lib/libgcc/libstdc++.6.dylib

dyld: Symbol not found: __ZNSo9_M_insertIeEERSoT_
  Referenced from: /opt/local/bin/cmake-orig
  Expected in: /opt/local/lib/libgcc/libstdc++.6.dylib

I get the same error with system apple gcc 4.2, on the same libgcc library... I wonder if this is a problem with the new gcc stuff

[ryandesign (Ryan Carsten Schmidt)]

Replying to rmottola:

  Referenced from: /opt/local/bin/cmake-orig

What's cmake-orig? I ​can't find any port installing that file.

[kencu (Ken)]

cmake-orig is installed by legacy support when binwrapping is enabled:

​https://github.com/macports/macports-ports/blob/479fd349ab673802018774b9c883f01fda93d6b5/_resources/port1.0/group/legacysupport-1.1.tcl#L243

[kencu (Ken)]

Riccardo -- I got the same error with cmake after the upgrade to libgcc14 as the default.

see #71503

However, a number of others said they did not get this error.

So we'll have to sort this out. This is the ABI inconsistency I was worried about, perhaps.

[kencu (Ken)]

So there is a possible big issue now with the upgrade to libgcc14.

Despite a number of folks saying they had used gcc14 and libgcc14 for months and months now without any trouble and zero problems of significance, two of us have seen this error so far.

It may simply be an issue of setting the c++ standard properly -- that would be a lucky outcome, if that is all this is.

Otherwise, this may be an ABI inconsistency with the build ... and in that case, worst-case scenario, we may have to revert the entire libgcc14 upgrade while it is sorted out properly.

And that would be a bit of a project.

[kencu (Ken)]

So I have bunch of things going on right now, so I will let the core players (barracuda, glebm) weigh in on fixing this for the time being.

I'll check in here in a while (after Christmas) and see what is going on.

If it hasn't been resolved by then, well "Houston, we may have a problem".

[rmottola (Riccardo)]

Comparing the errors I got in two failed package, the error appears to be always in cmake. It could be limited to this package. Perhaps others don't use it? Strange, cmake is a widespread build tool now.

I also wonder why it is on PPC only, I have not seen this error on Intel 32bit or 64bit, so it would be a strange ABI inconsistency.

[kencu (Ken)]

On my 10.5 Leopard PPC system, I am NOT seeing this error, and cmake is currently working just fine.

So -- something is inconsistent.

I had built several hundred ports on that LeopardPPC system with the gcc14/libgcc14 setup before committing the PR...

[kencu (Ken)]

eg building lilbjpeg-turbo (with your original reported build failure in this ticket) on my 10.5 PPC system just now goes smoothly through to completion.

Darwin LeopardG5.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh
LeopardG5:~ user$ sudo port -v destroot libjpeg-turbo
--->  Computing dependencies for libjpeg-turbo.
--->  Fetching distfiles for libjpeg-turbo
--->  Verifying checksums for libjpeg-turbo
--->  Checksumming libjpeg-turbo-3.0.4.tar.gz
--->  Extracting libjpeg-turbo
--->  Extracting libjpeg-turbo-3.0.4.tar.gz
Executing:  cd "/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_graphics_libjpeg-turbo/libjpeg-turbo/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/libjpeg-turbo/libjpeg-turbo-3.0.4.tar.gz' | /usr/bin/gnutar --no-same-owner -xf - 
--->  Configuring libjpeg-turbo
        (using ccache)
Executing:  cd "/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_graphics_libjpeg-turbo/libjpeg-turbo/work/build" && /opt/local/bin/cmake -G "CodeBlocks - Unix Makefiles" -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_INSTALL_PREFIX="/opt/local" -DCMAKE_INSTALL_NAME_DIR="/opt/local/lib" -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_C_COMPILER_LAUNCHER=/opt/local/bin/ccache -DCMAKE_CXX_COMPILER_LAUNCHER=/opt/local/bin/ccache -DCMAKE_Fortran_COMPILER_LAUNCHER=/opt/local/bin/ccache -DCMAKE_OBJC_COMPILER_LAUNCHER=/opt/local/bin/ccache -DCMAKE_OBJCXX_COMPILER_LAUNCHER=/opt/local/bin/ccache -DCMAKE_ISPC_COMPILER_LAUNCHER=/opt/local/bin/ccache -DCMAKE_C_COMPILER="$CC" -DCMAKE_CXX_COMPILER="$CXX" -DCMAKE_OBJC_COMPILER="$CC" -DCMAKE_OBJCXX_COMPILER="$CXX" -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_POLICY_DEFAULT_CMP0060=NEW -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_MODULE_PATH="/opt/local/share/cmake/Modules" -DCMAKE_PREFIX_PATH="/opt/local/share/cmake/Modules" -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH="/opt/local/lib" -Wno-dev -DWITH_JPEG8=ON -DCMAKE_OSX_ARCHITECTURES="ppc" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.5" -DCMAKE_OSX_SYSROOT="/" /opt/local/var/macports/build/_opt_macportsofficial_macports-ports_graphics_libjpeg-turbo/libjpeg-turbo/work/libjpeg-turbo-3.0.4 
-- The C compiler identification is GNU 4.2.1
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc-4.2 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_BUILD_TYPE = MacPorts
-- VERSION = 3.0.4, BUILD = 20240926
-- 32-bit build (powerpc)
-- CMAKE_INSTALL_PREFIX = /opt/local
-- CMAKE_INSTALL_BINDIR = bin (/opt/local/bin)
-- CMAKE_INSTALL_DATAROOTDIR = share (/opt/local/share)
-- CMAKE_INSTALL_DOCDIR = share/doc/libjpeg-turbo (/opt/local/share/doc/libjpeg-turbo)
-- CMAKE_INSTALL_INCLUDEDIR = include (/opt/local/include)
-- CMAKE_INSTALL_LIBDIR = lib (/opt/local/lib)
-- CMAKE_INSTALL_MANDIR = share/man (/opt/local/share/man)
-- Shared libraries enabled (ENABLE_SHARED = 1)
-- Static libraries enabled (ENABLE_STATIC = 1)
-- Arithmetic decoding support enabled (WITH_ARITH_DEC = 1)
-- Arithmetic encoding support enabled (WITH_ARITH_ENC = 1)
-- TurboJPEG API library enabled (WITH_TURBOJPEG = 1)
-- TurboJPEG Java wrapper disabled (WITH_JAVA = 0)
...
etc

[kencu (Ken)]

so either my cmake build is different than yours, or my libgcc14 build is different than yours it would appear.

let's see if we can sort out which with this:

$ md5 /opt/local/bin/cmake-orig
MD5 (/opt/local/bin/cmake-orig) = b58154072996feec4665753727cec790

$ md5 /opt/local/lib/libgcc/libstdc++.dylib
MD5 (/opt/local/lib/libgcc/libstdc++.dylib) = f1d2b486cd23eb38ec1eda19da891b11

presumably your cmake and libgcc14 builds should give you similar md5 checksums to mine... this is on 10.5 PPC ... do yours match mine?

[kencu (Ken)]

another data point -- I uninstalled cmake on my Tiger PPC installation that had the cmake error (see #71503), and just reinstalled cmake from source again.

and now cmake works fine, and I don't see the error about the missing symbol any longer, when building the same cmake-requiring ports that failed before.

So that is something strange. Apparently just rebuilding it has fixed it.

[kencu (Ken)]

cmake has just been updated to 3.31.2 -- and so it rebuilt again on Tiger and Leopard for me.

It needed one tiny patch to define one missing item on Tiger (I can push that if nobody else does first), but the new version is working properly for me on both Tiger PPC and Leopard PPC.

No errors about missing symbols (so far).

OK -- so there was something weird here, but it's not happening any more. Still, I have a feeling it will likely show up again somewhere, but as I / we don't yet understand what exactly happened, there is nothing yet to fix.

[fhgwright (Fred Wright)]

Is this a clue?:

MacPro:~ fw$ c++filt __ZNSo9_M_insertIeEERSoT_
std::ostream& std::ostream::_M_insert<long double>(long double)

[kencu (Ken)]

a bit -- I put that in my report too ​https://trac.macports.org/ticket/71503#comment:7 -- but not enough to sort it out for me yet.

I think between us all, we'll eventually sort it out.

Are you seeing this Fred?

[fhgwright (Fred Wright)]

Too early to say. My G4 mini (on 10.4) has finished the 22-hour build of gcc7-bootstrap and the 23-hour build of gcc10-bootstrap, is now working on libgcc14, and after that will need to build gcc14. All of which will presumably need to be repeated for 10.5.

Getting it installed on 10.5 i386 Rosetta will require more work, since it depends on help2man, which doesn't currently build for that configuration. Making a documentation tool a critical dependency of a toolchain component is utterly insane, but insanity should never be surprising where gcc is involved.

[kencu (Ken)]

I do remember a few things I read about this error over the years.

I believe:

1. It has to do with the change moving to c++11 for copy-on-write strings.
2. the functions were changed in the CXX11 ABI to do this properly
3. a dual-ABI functionality was maintained to allow interaction with software written for pre-c++11 libraries and executables. <​https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>
4. duplicates of some functions (like the facet functions, for example) were written, one for each ABI (_GLIBCXX_USE_CXX11_ABI=0 _GLIBCXX_USE_CXX11_ABI=1).
5. these duplicates exist but are really very rarely tested for _GLIBCXX_USE_CXX11_ABI=0 any more. As you know, MacPorts uses this setting to allow new software to interact with the ancient libraries in MacOSX 10.4 and 10.5 (and for barracude, 10.6-on-PPC).
6. the c++ standard being set by the build affects how these functions are exposed or hidden

In the gcc source tree, and in the gcc bug tracker, various hits come up when you search these terms.

Jonathan Wakely 's name seem to come up a lot when I read about this.

[kencu (Ken)]

I see this hint, which we might use sometimes when debugging things:

" Not all uses of the new ABI will cause changes in symbol names, for example a class with a std::string member variable will have the same mangled name whether compiled with the old or new ABI. In order to detect such problems the new types and functions are annotated with the abi_tag attribute, allowing the compiler to warn about potential ABI incompatibilities in code using them. Those warnings can be enabled with the -Wabi-tag option. "

[dpogue (Darryl Pogue)]

As another data point: over the past week I've been getting stuff set up on a brand new 10.5.8 32-bit PPC virtual machine. I installed gcc14, and then installed cmake, both with no issues (although the CMake version I got was 3.31.2, not 3.29.5).

My suspicion is that this error only shows up when existing dependencies were built with different compiler versions, which could make it harder to reproduce.

[fhgwright (Fred Wright)]

Replying to dpogue:

As another data point: over the past week I've been getting stuff set up on a brand new 10.5.8 32-bit PPC virtual machine.

You don't literally mean a "PPC virtual machine", do you? AFAIK, no such thing exists, though one can certainly have a PPC emulated machine. A more convenient way to do the latter is via Rosetta, but MacPorts doesn't do a good job of supporting Rosetta-targeted setups. Setting build_arch is only partially effective.

AFAIK, Apple's VM support is:

PPC: never
x86: 10.10+
arm64: 12.x+

It's especially annoying that they don't support an 11.x arm64 VM, even as a guest. That, in combination with the lack of a buildbot, is probably why several broken ports on 11.x arm64 go unnoticed, including gcc13 and gcc14.

[kencu (Ken)]

I have a QEMU PPC Tiger and PPC Leopard installation that runs on my arm64 M2 Mac (or any other system that qemu runs on).

It is actually usably fast, although compiling gcc is onerous.

(I really only use my G5s these past few years, however.)

[fhgwright (Fred Wright)]

Replying to kencu:

I have a QEMU PPC Tiger and PPC Leopard installation that runs on my arm64 M2 Mac (or any other system that qemu runs on).

And that's an emulation, not a "VM".

(I really only use my G5s these past few years, however.)

If I ever get around to doing an LCS overhaul, I could resurrect my Quad G5. Though one has to be careful relying on a G5 to test PPC code, since it will happily execute 64-bit instructions even when not in 64-bit mode.

[kencu (Ken)]

I also did see this link error a few weeks ago, when building cmake on Tiger PPC using gcc7 as the compiler with libgcc14 as the runtime, indicating the exact same missing symbol:

/opt/local/bin/g++-mp-7 -Wl,-headerpad_max_install_names -latomic -L/opt/local/lib -lMacportsLegacySupport -arch ppc -framework CoreFoundation -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc       -DCMAKE_BOOTSTRAP    -DCMake_HAVE_CXX_MAKE_UNIQUE=1   -I/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_devel_cmake/cmake/work/cmake-3.29.5/Bootstrap.cmk   -I/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_devel_cmake/cmake/work/cmake-3.29.5/Source   -I/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_devel_cmake/cmake/work/cmake-3.29.5/Source/LexerParser   -I/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_devel_cmake/cmake/work/cmake-3.29.5/Utilities/std   -I/opt/local/var/macports/build/_opt_macportsofficial_macports-ports_devel_cmake/cmake/work/cmake-3.29.5/Utilities  cmAddCompileDefinitionsCommand.o cmAddCustomCommandCommand.o cmAddCustomTargetCommand.o cmAddDefinitionsCommand.o cmAddDependenciesCommand.o cmAddExecutableCommand.o cmAddLibraryCommand.o cmAddSubDirectoryCommand.o cmAddTestCommand.o cmArgumentParser.o cmBinUtilsLinker.o cmBinUtilsLinuxELFGetRuntimeDependenciesTool.o cmBinUtilsLinuxELFLinker.o cmBinUtilsLinuxELFObjdumpGetRuntimeDependenciesTool.o cmBinUtilsMacOSMachOGetRuntimeDependenciesTool.o cmBinUtilsMacOSMachOLinker.o cmBinUtilsMacOSMachOOToolGetRuntimeDependenciesTool.o cmBinUtilsWindowsPEGetRuntimeDependenciesTool.o cmBinUtilsWindowsPEDumpbinGetRuntimeDependenciesTool.o cmBinUtilsWindowsPELinker.o cmBinUtilsWindowsPEObjdumpGetRuntimeDependenciesTool.o cmBlockCommand.o cmBreakCommand.o cmBuildCommand.o cmCMakeLanguageCommand.o cmCMakeMinimumRequired.o cmList.o cmCMakePath.o cmCMakePathCommand.o cmCMakePolicyCommand.o cmCPackPropertiesGenerator.o cmCacheManager.o cmCommand.o cmCommandArgumentParserHelper.o cmCommands.o cmCommonTargetGenerator.o cmComputeComponentGraph.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmComputeTargetDepends.o cmConsoleBuf.o cmConditionEvaluator.o cmConfigureFileCommand.o cmContinueCommand.o cmCoreTryCompile.o cmCreateTestSourceList.o cmCryptoHash.o cmCustomCommand.o cmCustomCommandGenerator.o cmCustomCommandLines.o cmCxxModuleMapper.o cmCxxModuleUsageEffects.o cmDefinePropertyCommand.o cmDefinitions.o cmDocumentationFormatter.o cmELF.o cmEnableLanguageCommand.o cmEnableTestingCommand.o cmEvaluatedTargetProperty.o cmExecProgramCommand.o cmExecuteProcessCommand.o cmExpandedCommandArgument.o cmExperimental.o cmExportBuildFileGenerator.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportSet.o cmExportTryCompileFileGenerator.o cmExprParserHelper.o cmExternalMakefileProjectGenerator.o cmFileCommand.o cmFileCopier.o cmFileInstaller.o cmFileSet.o cmFileTime.o cmFileTimeCache.o cmFileTimes.o cmFindBase.o cmFindCommon.o cmFindFileCommand.o cmFindLibraryCommand.o cmFindPackageCommand.o cmFindPackageStack.o cmFindPathCommand.o cmFindProgramCommand.o cmForEachCommand.o cmFunctionBlocker.o cmFunctionCommand.o cmFSPermissions.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluationFile.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyCommand.o cmGetFilenameComponentCommand.o cmGetPipes.o cmGetPropertyCommand.o cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmGlobVerificationManager.o cmHexFileConverter.o cmIfCommand.o cmImportedCxxModuleInfo.o cmIncludeCommand.o cmIncludeGuardCommand.o cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o cmInstallCommand.o cmInstallCommandArguments.o cmInstallCxxModuleBmiGenerator.o cmInstallDirectoryGenerator.o cmInstallExportGenerator.o cmInstallFileSetGenerator.o cmInstallFilesCommand.o cmInstallFilesGenerator.o cmInstallGenerator.o cmInstallGetRuntimeDependenciesGenerator.o cmInstallImportedRuntimeArtifactsGenerator.o cmInstallRuntimeDependencySet.o cmInstallRuntimeDependencySetGenerator.o cmInstallScriptGenerator.o cmInstallSubdirectoryGenerator.o cmInstallTargetGenerator.o cmInstallTargetsCommand.o cmInstalledFile.o cmJSONHelpers.o cmJSONState.o cmLDConfigLDConfigTool.o cmLDConfigTool.o cmLinkDirectoriesCommand.o cmLinkItem.o cmLinkItemGraphVisitor.o cmLinkLineComputer.o cmLinkLineDeviceComputer.o cmListCommand.o cmListFileCache.o cmLocalCommonGenerator.o cmLocalGenerator.o cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o cmMakefile.o cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsCommand.o cmPathLabel.o cmPolicies.o cmProcessOutput.o cmProjectCommand.o cmValue.o cmPropertyDefinition.o cmPropertyMap.o cmGccDepfileLexerHelper.o cmGccDepfileReader.o cmReturnCommand.o cmPlaceholderExpander.o cmPlistParser.o cmRulePlaceholderExpander.o cmRuntimeDependencyArchive.o cmScriptGenerator.o cmSearchPath.o cmSeparateArgumentsCommand.o cmSetCommand.o cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o cmSetTestsPropertiesCommand.o cmSiteNameCommand.o cmSourceFile.o cmSourceFileLocation.o cmStandardLevelResolver.o cmState.o cmStateDirectory.o cmStateSnapshot.o cmString.o cmStringAlgorithms.o cmStringReplaceHelper.o cmStringCommand.o cmSubcommandTable.o cmSubdirCommand.o cmSystemTools.o cmTarget.o cmTargetCompileDefinitionsCommand.o cmTargetCompileFeaturesCommand.o cmTargetCompileOptionsCommand.o cmTargetIncludeDirectoriesCommand.o cmTargetLinkLibrariesCommand.o cmTargetLinkOptionsCommand.o cmTargetPrecompileHeadersCommand.o cmTargetPropCommandBase.o cmTargetPropertyComputer.o cmTargetSourcesCommand.o cmTest.o cmTestGenerator.o cmTimestamp.o cmTransformDepfile.o cmTryCompileCommand.o cmTryRunCommand.o cmUnsetCommand.o cmUVHandlePtr.o cmUVProcessChain.o cmVersion.o cmWhileCommand.o cmWindowsRegistry.o cmWorkingDirectory.o cmXcFramework.o cmake.o cmakemain.o cmcmd.o cm_fileno.o cmDepends.o cmDependsC.o cmDependsCompiler.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmProcessTools.o fs_path.o string_view.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmExprLexer.o cmExprParser.o cmGccDepfileLexer.o cmListFileLexer.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o Status.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o uv-src-strscpy.c.o uv-src-strtok.c.o uv-src-timer.c.o uv-src-uv-common.c.o uv-src-unix-cmake-bootstrap.c.o uv-src-unix-core.c.o uv-src-unix-fs.c.o uv-src-unix-loop.c.o uv-src-unix-loop-watcher.c.o uv-src-unix-no-fsevents.c.o uv-src-unix-pipe.c.o uv-src-unix-poll.c.o uv-src-unix-posix-hrtime.c.o uv-src-unix-posix-poll.c.o uv-src-unix-process.c.o uv-src-unix-signal.c.o uv-src-unix-stream.c.o uv-src-unix-tcp.c.o uv-src-unix-tty.c.o rhash-librhash-algorithms.c.o rhash-librhash-byte_order.c.o rhash-librhash-hex.c.o rhash-librhash-md5.c.o rhash-librhash-rhash.c.o rhash-librhash-sha1.c.o rhash-librhash-sha256.c.o rhash-librhash-sha3.c.o rhash-librhash-sha512.c.o rhash-librhash-util.c.o jsoncpp-src-lib_json-json_reader.cpp.o jsoncpp-src-lib_json-json_value.cpp.o jsoncpp-src-lib_json-json_writer.cpp.o  -o cmake
Undefined symbols:
  "std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long double>(long double)", referenced from:
      cmGlobalGenerator::Configure()      in cmGlobalGenerator.o
      cmGlobalGenerator::Generate()      in cmGlobalGenerator.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status

chatgpt had a lot to say about that error, starting with this:

" The error you are encountering indicates a problem with the linking process, specifically with an undefined symbol in the std::ostream template for long double. This can happen due to mismatched or missing C++ standard library implementations, ABI differences, or misconfigured compiler and linker flags. "

[kencu (Ken)]

duplicates of this are starting to show up in the ticket reports as others try to build things. I won't bother to clutter up this ticket with endless reports of the duplicates.

we'll see if these all go away with rebuilding cmake, or if they do not...

[mascguy (Christopher Nielsen)]

Riccardo, is this still an issue?

[mascguy (Christopher Nielsen)]

Replying to mascguy:

Riccardo, is this still an issue?

If this is still an issue, please reopen this ticket.