clang++: error: unsupported option '-fsanitize=leak' for target 'x86_64-apple-darwin23.6.0'

[ClausKlein]

bash-5.2$ cmake --workflow --preset gcc-debug  
Executing workflow step 1 of 3: configure preset "gcc-debug"

Preset CMake variables:

  CMAKE_BUILD_TYPE="Debug"
  CMAKE_CXX_COMPILER="g++"
  CMAKE_CXX_FLAGS="-fsanitize=address -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak -fsanitize=undefined"
  CMAKE_CXX_STANDARD="17"

-- The CXX compiler identification is AppleClang 16.0.0.16000026
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ - broken
CMake Error at /usr/local/Cellar/cmake/3.30.5/share/cmake/Modules/CMakeTestCXXCompiler.cmake:73 (message):
  The C++ compiler

    "/usr/bin/g++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/Users/clausklein/Workspace/cpp/beman-project/exemplar/build/gcc-debug/CMakeFiles/CMakeScratch/TryCompile-h6rdZf'
    
    Run Build Command(s): /usr/local/bin/ninja -v cmTC_abf57
    [1/2] /usr/bin/g++   -fsanitize=address -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak -fsanitize=undefined  -std=gnu++17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.1.sdk -mmacosx-version-min=14.7 -MD -MT CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -MF CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o.d -o CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -c /Users/clausklein/Workspace/cpp/beman-project/exemplar/build/gcc-debug/CMakeFiles/CMakeScratch/TryCompile-h6rdZf/testCXXCompiler.cxx
    FAILED: CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o 
    /usr/bin/g++   -fsanitize=address -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak -fsanitize=undefined  -std=gnu++17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.1.sdk -mmacosx-version-min=14.7 -MD -MT CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -MF CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o.d -o CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -c /Users/clausklein/Workspace/cpp/beman-project/exemplar/build/gcc-debug/CMakeFiles/CMakeScratch/TryCompile-h6rdZf/testCXXCompiler.cxx
    clang++: error: unsupported option '-fsanitize=leak' for target 'x86_64-apple-darwin23.6.0'
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:5 (project)


-- Configuring incomplete, errors occurred!
bash-5.2$ 

[ClausKlein]

You may find some good inspiration for modern C++ with CMake using workflow presets here:
ClausKlein/cmake-init-modules#4

i.e ci.yml
and CMakeUserPresets.jsonnet

[camio]

I was able to reproduce this on OSX with Apple silicon. The issue is that OSX has a g++ executable that isn't gcc, it's Apple clang.

(base) dsankel@Davids-Mac-Studio exemplar % /usr/bin/g++ --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Apple clang doesn't have a "leak" sanitizer like gcc does. One way to fix is to add clang-debug/clang-release presets and point people to those when they're on an OSX platform.

[ClausKlein]

. One way to fix is to add clang-debug/clang-release presets and point people to those when they're on an OSX platform.

An other way is to use a Module like Sanitizers.cmake and keep the preset generic.

Same for compiler warnings: CompilerWarnings.cmake

This has also the advantage of not propagating the Sanitizer settings, coverage compile flags, or CompilerWarnings to the external projects used with FetchContents.

See for usage examples

[wusatosi]

is the fix going to be bundled into #66?

[wusatosi]

Would compiler detection + a tool chain file solve this issue?

May relate: #44 (review) ?

[ClausKlein]

is the fix going to be bundled into #66?

Yes

[steve-downey]

This has also the advantage of not propagating the Sanitizer settings, coverage compile flags, or CompilerWarnings to the external projects used with FetchContents.

Although for memory and thread sanitizer you must propagate the settings, or the sanitizers don't work.

[steve-downey]

Would compiler detection + a tool chain file solve this issue?

Toolchain would probably help here. I find it worth it, just to have a single identifier to consolidate the dimensions across the far too many compilers I have locally. I'm lucky I can usually ignore OS, bundling that into the "compiler" choice.
Toolchains are also easier to maintain individually rather than the monolithic presets and user presets files. Those are geared for a small set of common workflows.

[steve-downey]

Yes

Also answers my question on the PR.

I'll check into what our (mostly self supported) darwin builds are doing in this situation. The default style in house is Lakosian foobar.{cpp/h/t.cpp} triples even if the cpp file is empty other than including the header. It ensures that the header builds, and on some of our older vendor compilers avoided weird link issues with the vtbl not being found. Also made it easier when something was found that did need to be in the cpp file rather than the header.

The newer VERIFY_INTERFACE_HEADER_SETS would fix the broken header problem. Tracking down errors showing up in downstream usage can be frustrating. "Shifting left" finding the typo in the header helps. It's why we run unit tests in our package builds, too.